私はWebシステムに関するITエンジニアをやっておりますが、運用保守エンジニアをやっていたときに炎上プロジェクトよりスリリングな地獄を見たことがあります。
この記事では、私が運用エンジニアのチームに所属していたときに体験したその地獄の詳細について話したいと思います。
地獄のような体験をお話する前に、開発エンジニアと運用保守エンジニアの違いについて説明します。
開発エンジニアと運用保守エンジニアの違い
開発エンジニア
ソフトウェアのシステムにおいて、設計・プログラミング製造・テストを行い、主にシステムを開発するエンジニアのことを指します。
少数精鋭の場合に多いのですが、運用から保守まで全般的なことを開発エンジニアが担当する場合もあります。
運用保守エンジニア
サーバーやネットワーク、システムなどを安定的に稼働させるために、運用管理やメンテナンス、障害対応などを行うエンジニアでインフラエンジニアと呼ばれていることもあります。
開発エンジニアと運用保守エンジニアの役割が完全に分かれてしまっている場合には、開発エンジニアが開発したシステムで障害が発生した場合は、運用保守エンジニアが対応することになります。
何が起きたのか？
冒頭で挙げた地獄のような体験というのは、私が運用保守エンジニアをやっていた時の話で、開発エンジニアが開発したWebシステムをリリースした後に不具合が発生してDBのデータを破壊してしまうというものでした。
正確に言えば、破壊というよりは改修箇所の不具合によって、誤ったステータスで既存のデータを上書きしてしまい、さらに関連するテーブルのデータと不整合が起きてしまい、データベース全体のぐちゃぐちゃになってしまうという恐ろしいものでした。
何がヤバイのか？
運用保守経験がない方だと何がヤバイのかは分からないと思いますので、その部分を説明していきたいと思います。
まず、最初に思うのはリリース前にバックアップしたDBに戻せばいいんじゃね？って話だと思います。
しかし、そんな単純な話ではありません。
なぜなら、リリースした後もDBのデータはシステムを利用するユーザによってリアルタイムで更新され続けているので、もしリリース前の状態に戻してしまったら、その間に操作したデータも戻ってしまいます。
例えるなら仮で銀行系のシステムだったとすると、リリースした後で100万円の振り込みをしたとして、DBを戻すとそれがなかったことになってしまうということです。そんなことがあったら誰でもヤバイことだということはお分かりいただけると思います。
そのため、バックアップでDBを戻すことはできません。
DBを戻すことができない……ではどうすればいいか？
答えは、破壊されてしまったデータの整合性を正しいものに補正しなければならないということです。
これがとてつもなく大変な作業になります。
それは後述で説明しますが、リリース後に発生したこの障害ではもう一つやらなくてはなりません。
それは開発チームがリリースしたシステムの不具合を修正しなくてはいけないということです。しかもリリースされてリアルタイムで動いてしまっているので、早急に不具合の原因を特定して修正しなければならないということです。
しかも、しかもですよ……この不具合が発覚したのは、早朝リリースがあって夕方の定時直前です。
つまり、通常勤務8時間を終えて、
ダメ系今日も疲れたー、さて退勤するかー
と思っていたときです。
果たしてこの後、どうなったのでしょうか？
最終的にどうなったのか？
結論から言うと、朝まで計24時間勤務の対応をして障害を解消することができました。
24時間勤務ですよ……頭は回らないわ、集中力は続かないわ、チームは緊迫感で雰囲気は悪いわで地獄絵図でした。
運用保守エンジニアは、24時間いつもで障害が発生したときに対応できるようにシフト勤務になっている現場もありますが、私が所属していた現場では基本的に深夜に対応しないことを前提としていたので、開発チームと運用保守チームで日中帯の同じ時間に勤務していましたので、よりによって退勤後から長時間にわたる障害対応になってしまったのは地獄の要因でした。
そして、何より地獄だったのが作業内容です。
まとめると以下の障害対応が必要でした。
- リリースしたモジュールの不具合の原因を特定する
- モジュールの不具合を修正して再リリースする
- 不具合で破壊されたDBのデータを修正して正しいものにする
この中でDBのデータを修正するのが一番大変な作業でした。
不具合の原因を特定した後で、DBでステータスを誤って書き換えてしまったデータを特定できたのですが、思った以上のデータ量かつ関連する多岐のテーブルへの修正も必要になってしまったからです。さらに本番環境のデータなので、修正漏れや誤った正しいデータを書き換えてしまう二次災害のミスは絶対に許されません。
しかも休憩を取っていないので勤務を続けていたので集中力は限界を迎えていましたが、そんな最悪なパフォーマンスの中、やるしかありませんでした。やるしかないのです！
この破壊されたデータを特定はどうやったのか？ということですが、DBのテーブルには更新日時を持っておりましたので、リリース後以降に更新されたデータを全て抽出してそれを正しいデータに書き換える対象としました。そして、正しいステータスで書き換えるというのはひたすらユーザによって操作されたログを抽出して、ユーザが操作した通りにテーブルに登録、更新、削除をしていくということを繰り返す地道でミスの許されない作業でした。
そして、数名の運用保守チームメンバーと協力しながらモジュールの不具合を原因調査する人、破壊されたデータを特性する人、データを補正するSQLでINSER、UPDATE、DELETE文を作成する人、モジュールの不具合を修正する人といった感じで担当を割り振って、睡眠不足と緊張感のある作業と戦いながら対応を行うことができました。
しかし、それで終わりではなく、次の日も通常勤務の日だったので、3時間程度仮眠としてから勤務を続けたことも含めて地獄だったというのは言うまでもありません。
まとめ
この記事では、私が運用保守エンジニアとして働いていたときに体験した恐怖の障害の話をしました。
Web系のシステムにおいて、リリース後に不具合が発生した場合、モジュールの不具合を修正するだけで解決する軽微なものだったら良いのですが、既存のDBのデータを破壊して不整合を起こしてしまう不具合が起きてしまった場合は、リリース前のDBの状態に戻せなくなり、本番環境で破壊されたデータを正しく書き換えなくてはならなくなってしまうので、デスマーチのような作業になってしまいます。
だからこそ、そういった事態にならないように開発エンジニアはテストを徹底して重大な不具合を本番環境で起こさないようにしなくてはなりません。
そして、運用保守エンジニアは縁の下の力持ちと言われることもありますが、緊急度の高い障害を短い時間の中で特定し対応するという作業は開発エンジニアとは違った高度な能力が必要となります。
今は開発エンジニアのチームとして仕事をしていますが、保守運用エンジニアのチームメンバーにはいつも記事で紹介したような障害に備えて仕事をしていて、困ったときは助けて頂いて日々感謝しています。
この場を借りて言わせてください。
ダメ系保守運用エンジニア様、いつもありがとうございます！
