今日はバグ見つけて急いで直してリリース作業をしたのだけど、その際に痛いミスをした。
幸い、相手が適切に判断を下してくれたので、大事故にはならなかったので良かったが、少なからず混乱を招いた
何があったのか
ちょっと長くなるが先に、どのようなシステム構成か、どのようにリリース作業をやっているか述べる必要がある。
Webシステムを構成するために、いくつか小システム(以下、システムA,B)があり、連携して実現している。
そのシステムAに関わってる一人に私がいる。
リリース作業をするとき、必ず事前にこういうことをやる、というのを「運用チーム」へ共有する。
運用チームは、システム監視とネットワークの制御を行っている。
最近は非停止でリリース作業する。非停止でないと、顧客への利用影響が出るため、停止期間を顧客に周知したり期間が必要なので、時間もより多くの手続きも必要になる。
なので、システムAもシステムBも複数台の冗長構成をとり、非停止でリリースが出来る形にしている。
リリース作業のフローはこうなっている。
- 運用チームにシステム監視を外してもらう
- サーバの停止を伴うことがあり、それが監視に見つかると、障害対応しなくてはならない。なので、リリース作業中は見逃してもらう。
- 運用チームにシステムの1台目のサーバへ、アクセスが行われない形にしてもらう(以下、切り離し作業)
- 運用チームから作業完了の連絡を受け、サーバ上から切り離し作業されていることを確認したら、リリース作業を開始
- リリースが終わったら、運用チームに連絡し、システムの1台目のサーバへアクセスを行われる形にしてもらう(以下、戻し作業)
- 運用チームから作業完了の連絡を受け、戻し作業が終わって1台目のサーバへアクセスが着始めたら、2台目の作業を行うため、運用チームにシステムの2台目のサーバの切り離し作業をしてもらう。
- 運用チームから作業完了の連絡を受け、サーバ上から切り離し作業されていることを確認したら、リリース作業を開始
- 以下、台数分繰り返す
- 終わったら最後にシステム監視を元に戻してもらう
つまり、我々の判断でネットワークから切り離す、ということができないので、運用チームにお願いしている。
また、この連絡の手段がメールであるため、1つのシステム宛にccで送られてくる。(システムAの作業内容がシステムBの担当者にも届く)
今回やらかしたのは、
システムAの1台目の作業が終わり、2台目の作業待ちとなっていたとき(上記(6)を待っているとき)に、システムBの2台目の切り離し作業完了連絡を受けて作業を始めてしまったこと。つまり、確認するべきメールを間違えて上に間違えたメールの返信で返してしまい、作業を始めてしまったということ。
「切り離し作業されていることを確認したら」という条件も満たしていたので、システムA的には問題なかったが、勝手にシステムBの応答を返された方は溜まったものではないだろう。
2台目サーバの作業完了のメールを送った直後に気づいた後の対応もひどくて、メールで前の2件は破棄するよう依頼したこと。
幸い、リリースの作業の担当者が決まっていることや、件名や本文中にシステム名が書いてあることから、運用チームはシステムBの連絡に別のシステムの担当者からメールが来ていて内容も変だ、と気づいていたため、内部でハンドリングしてもらい、大事にはならなかった。
システムBの担当者の席が近かったのもあり、口頭で「これ間違いだよね？」と確認があったため、システムBにも影響はなかった。
どうすればよかったか
- 件名、内容、宛先の担当者の確認をしっかり行うべき
- 誤ったことに気づいた時点で、メールではなく、電話などですぐに連絡がつく手段で第一報を知らせるべき
当然めちゃんこ怒られて気分がブルーになったわけですが、全部自分が悪いので、次は作業手順に組み込んで確認チェック項目を増やします、という対応をしようかなーと思ってる。
棚上げ
とても反省したので、以降は自分が悪いのを棚に上げて言う。
作業連絡にメールはダメだと思う
まずなぜ、非同期通信の筆頭であるメールを使うのか。
- 運用「システムBの作業開始してください」
- システムA「作業開始します」
- システムA「〜作業中〜」
- 運用（えっ、ちょｗ）
- システムA「作業完了しました」
- 運用「」
これじゃ運用が気づいても手遅れ。
こっちの手順不足で「サーバ上から切り離し作業されていることを確認したら」という点がなかったらまた事故ポイント増えますですよ。
なので作業開始確認を送るようにしたらどうか？
- 運用「システムBの作業開始してください」
- システムA「作業開始しますが、よろしいですか？」
- 運用「お前じゃねえ、座ってろ」
- システムA「あっ・・・(察し) すみませんでした」
多分、防げる。でもただでさえ10分前後応答待ち時間があるのに、こんなことしてたら、終電にさよならバイバイどころか、日が明けちまう。
メールじゃなくてチャットだったらもう少しマシかもしれないが、それでも5分以上は待つだろう。
リリース作業を手でやるな
そもそもなんでこんな手作業感が満載なんですかね？
運用にネットワーク牛耳られてるのはまだ良いとして、タイミングぐらいこっちで決めさせてほしい。
- 12:10〜12:20は1台目を自動で切り離すなり
- APIで切り離しさせたりするなり。○IG-IPにそういう製品があるかしらないけど。
- リクエストが1万/secぐらいなら、ngi○xとかのgraceful reloadを試すなり。reload直前に来て処理中のリクエストも、処理中リクエストがreload前の古いプロセスでちゃんと処理されると聞いてます。
人が間に入るとミスしていたことに気づいたときのリカバリはしやすいだろうけど、人の思惑や個人差が入る。今回のミスにミスを重ねたところだって、「メールでやり取りしてるからメール送ればいいでしょ」って思ってた節はある。今思えばクズの極みだな！
人の違いでミスがリカバリできたり、取り返しがつかなく事はあるんだけど、今回は人が間に入っていなければ各システムのペースで出来たんじゃ、と思う。もし切り離しのミスがあっても責任転嫁出来る以外にメリットが浮かばない。足枷な感じがしてならない。
そもそも、一番最初に要件聞いたりしたときにそんな形でリリースしていくなんて話出てなかったし、いざ本番環境にリリースするぞ！ってなってからこういう運用だからって聞かされたら何もできない。検証環境でやったフローと全然違うやん。
リリース作業なんて何十回やったかわからんけど、リリース作業による工数や人件費は結構馬鹿にならなくて、本来計上されてなかった緊急対応もそれなりの体制を組んでやってるから残業代も増える。まぁ、委託側の人件費(1人当たりの単価)は月固定らしいんで残業させようが受託側の懐が痛むだけなんですが。なんか、ミスさせて単価を安くする交渉材料を作ってるようにしか思えない気もしてきた。
どうしたいか
本音を言えば、リリース作業は自動化したい。今の手順じゃ切り戻し、切り離しに運用チームが挟まる以上、ここをどうするか考えないといけないけど。それなら運用チームに順番にコマンド叩いてもらう方法とかどうか。でも自分たちの余計な作業は増やしたくないだろうから、それはできないとか言われそうだ。
でも今月で落ち着くはずだし今更感ある。保守フェーズに入るだろうけど形だけで、次にどっかの仕事の穴埋め役で放り込まれるんだ。現在も別プロジェクトの保守(エラー原因の調査依頼があれば対応)をしつつ、今の仕事を掛け持ってるんだし、そうなるんだろうなーとか思ってる。
「確認する」作業が向いてない
人間として色々おかしいと思われるかもしれないけど、「確認する」っていう作業がとても苦手だと思ってる。
ちょっと仕事の都合でお出かけした際の月1の清算の計上では何度も指摘くらって戻される。明らかに違うのになぜ異常かってわからないのかわからないほど気づけない。
「自分は完璧だ」とか「今回は大丈夫」といった思い込みからきてるのかもしれないけど、今までこんな調子なんだから治らないもんは治らない。チェックリスト作ってこの通りチェックしました、というしかないんだろう。
ミスに気づいたときの対処法といい、尤度よりも自分の都合が良い方法ばかり選ぼうとしてる。結局、全部自分のせい。
