企業・官公庁ユーザーが8割を占める実績と信頼…
大変なことになっていました。。
このようなことは起きてはいけない大問題とはいえ、いつ何時どこで起きるかわからないもの。
堅実に組まれたシステムでも、ヒューマンエラーを起こすかもしれない。
そんな時に私たちがすべきことは起きてしまったことを批判ではなく、
これをきっかけに前進するための話です。
事の顛末は、FSVの中間報告から転載させて頂きます。
6月20日に起こった事は…
脆弱性対策を特定のサーバに対して実施…のはずが、
1：更新プログラムの不具合
2：検証すべき項目の漏れ
3：バックアップの仕様に不備
という原因で、サーバ上に保管されていたデータが飛んだ＼(^o^)／
…ということ…
どうしてこーなった!!と騒ぐ事は誰でもできること。
｢どうすれば未然に防げるか｣を考えないといけません。
まず1つ目の原因を未然に防ぐには…昔言われたんですよね。
削除や停止する系のプログラムを書く時は｢まず対象や止めるコードを書け｣と。
そうすれば未然に動かしすぎることはないはずだと。
その当時、PG1年目の私は
｢怖いから言われなくてもそっちから書くわー。
とりあえずログも全部書き留めるわー。
もー要らんほどバックアップも取っちゃうっ!!
ていうか新人にバッチなんて書かすなー(泣｣
…とパニックになりながら無駄なこともやってました←
その｢無駄｣は経験によって省かれていきます。
しかし、その｢無駄｣が省かれた時こそが怖いんです。
｢慣れ｣や｢油断｣。
サルPGは人に進化してザルへと化してしまう事があります。
手順化された事も｢わかってる分かってる～｣と流してしまえば無いのと同じ。
とても意識的なお話で、｢ダブルチェックを実施｣では絶対とは言い切れないのがつらい所です。
パニックになった次の年
｢kill(強制終了コマンド)…(Enterキーをスパーンッ)｣とプロセス全部止めたのは懐かしい思い出です☆
…リリース前でよかった…
とはいえ｢更新プログラムの不具合｣はあって然るべきと考えます。
2つ目の原因、｢検証の漏れ｣さえなければ防げたものなのです。
今回の場合、
・｢Aに反映｣を証明するには、｢A以外には反映されていない｣を確認しないといけない
・｢Bを削除｣を証明するには、｢B以外は削除されていない｣を確認しないといけない
この2点の真偽を網羅できていなかったというのが｢漏れ｣になるでしょう。
検証の漏れを防ぐために有効なのは｢クロスチェック｣だと言われます。
組んだ本人でない人にテストをさせる。
そう…他人(特に上長)の揚げ足取りを公然にできる機会なのですっ!!!
今回の原因、｢命令網羅｣や｢条件網羅｣、｢分岐網羅｣は
基本的な事であって前述のような｢慣れ｣や｢油断｣で自分には甘くなったとしても、
クロスチェックで他人には容赦なくぶちかまします(｀･ω･´)
起こった時はちょっとめんどくさいSQLインジェクション
そんなことやんのかよ!!っていうイレギュラーなテスト…
自分が直すのではないのでとりあえず、思いつく限りやってやります(｀･ω･´)
障害報告書を書いては、女子高生の手紙ように丁寧に折りたたんで
先に帰った上長の机に山積みにしてあげるのが流行ったりもしました(私の中だけで)
結合テストなのに単体テストぽいこともしちゃるっっ!!…と上長に対してやっていたら、
これ幸いと上長がUTしなくなりました。…いい思い出ですね…orz
ザルにならないように障害報告書の数で競い合ったりするのも｢心掛ける｣という上では良いと思うのです。
このフェーズ終わった時に一番多かったヤツの奢りで飲みなーとか。
間違っても、私が当時居た会社のように｢一番多かったヤツが一番堪える羞恥プレイ｣なんてものを設定してはいけません。
そして3つ目のバックアップの仕様に関して。
｢何故(脆弱性の)アップデートをかけてるのか｣見解の分かれる所だと思いますが
この原因はバックアップの仕様というか…アップデートに対するフローだと思います…
この流れのように本番環境と同時にバックアップへアップデートをかけた時、
今回の｢不具合｣でなくとも、例えば停電が起こったらどうなっていたのでしょう。
本番環境もバックアップも同時にプログラムを流して…途中でパチン!!
これではバックアップにも｢何らかの影響｣があって本番環境を元へ戻すこともできません。
バックアップは｢本番環境に何かあった時に切り戻せるもの｣だと考えます。
｢本番環境に何かあった時｣はどんな時に多いか…？
それは、このような更新のタイミングでしょう。
このフローだと、｢バックアップ｣はバックアップをなしていない…
これを未然に防ぐには
リリース計画の定期的な見直しが必要なのかと私は考えます。
勿論、最初のリリース計画や業務のフローが｢文句ない!!｣｢素晴らしい!!｣なんてモノであれば良いのかもしれません。
でも、スタンダードな対応は変化するものだし、
きっとその内考えの違うヤツが入ってきたりして
より良い結果が導かれるのではないかと思います。
…まぁ、全部論破してやりますけどね(違
今回は世間でウワサな問題から｢どうすれば良いか｣を考えましたが、
それが自分に起こったことであっても｢失敗する｣ ｢問題が起きる｣ことは、致命的でない限り
省みることで次へ繋げるチャンスだと思うのです。
致命的でない限り…もうね…プロセスつーかジョブつーか全部強制終了したのトラウマなの…
私、Tomcat再起動したかったの…killのが早いとかささやかれたのっ…うっうっ…(´;ω;｀)
そして、もちろん｢もし自分達が(今の立場で)このような事態に関わった時にどのように対処すべきか｣を考えないといけません。
考えないと…か、考えるからあつまってぇー>(；´Д｀)ﾉ