大規模システムリリースの朝に。
先日久方ぶりの大規模リリースがありました。なんとかつつがなく終わり、関係者全員ほっとしています。
リリースは、それまでの準備が９割９分
以前はシステムリリースの日にバタバタするというのがよくありましたが、今はそんなことはなくて、作業計画でやるべきことを行って、淡々とリリースをして、動作確認をする感じです。
リリース自体はその前にされていて、サイトopen＆動作確認が主とかですね。
どちかというとおつかれさまって感じ
基盤からのリリースは超緊張します
半面、超大規模システムで、新しい基盤でやるなんていうときにはかなりドキドキしますね。
以前立ち会ったシステムリリースでは、AWSを初めて導入した案件で、あれこれうまくいっていなかったこともあり、朝の6:00から、サービス側のアプリベンダー・業務システム側の保守ベンダー・インフラベンダーと全員そろって当日を迎えました。
リリース報告は10:00予定。
ふたを開けてみたら、こんな感じですよ。
・朝7:00時点でインフラがつながらない
・あれこれ格闘してインフラはつながる
・アプリケーションの一部がうまく動作しない→リリースの問題だった
・データ移行が終わってないことが判明→アウト！！！
準備が整ってなくて、当日しかできなかったんだ、こりゃ。
結論として、全部のデータ移行が終わったのは11：00を回っておりました。。。
作業を前もって見える化せよ！
上の事象もそうですが、こういったことの原因っていくつか決まりきったパターンがあって、
・作業者だけが知っている作業がある
・初めての作業をいきなり本番でやろうとする
・適切な作業時間や人員配置を取っていない
で、上の事象は、そもそもデータ移行をいきなりやるなんて聞いていなかったわけです。
つーか、そもそもデータ移行があるなんて、聞いてなかったの。
ベンダーの担当者だけが知っていたの。
で「遅いなー」と思ったら「実は…」となったの。
まあ当時、実は「リリース手順書」などもしっかり決めていなかったので、しょうがないかな。
今は手順書をきちんと用意してやっていますよ、
間に合わない場合のプランを考えておく
まあこんなの考えておきたくはないのですが、下記のようなことは考えておくようにしています。
・作業進捗の確認ポイントを持つこと（ブロックごとに単位を持つ）
・うまくいかない場合の連絡体制（誰を待機させておくか）
・うまくいかない場合の連絡方法
・切り戻しができるかどうか
・切り戻しができない場合、プランＢをどうするか
書いていて胃が痛くなってきましたよ(笑)。
「すみません。切り戻せないので、このまま突っ走るしかありません」と言われて、泣いた。
ちなみに、よくあるのは「何もしていないはずだった人が作業を予定していてそれが全体に影響を及ぼす」ってやつですねえ。。
今はほぼないけどね。
ちなみにこのマンガでも、インフラチームの作業が原因でシステム負荷が上がっちゃってリリースがうまくいかなかったとかありましたね。
読んでいて胃が痛くなります(笑)
しかしまあ、だいたい中小企業の大規模リリースなんて、全部予定通り整っているケースなんてなくてですねー。
計画性を持ってやっていても、準備が十分間に合っていなかったり、確認が足りていなかったりして、だいたい何か足りてないの(´;ω;｀)
なので、どちらかというと「完全にはうまくいかない」ことを前提に連絡体制や切り戻しなどを考えています。
あとは、基本的な障害対応のフローを作っておけば、問題が起きてもあわてずに対応を取れるというのはあると思います。
この本はそういった意味で、とても良書。
おしまい。
この記事が気に入ったらサポートをしてみませんか？