前々回記事はこちら→システム開発業界で経験したくない事個人的トップ5 前編
前回記事はこちら→システム開発業界で経験したくない事個人的トップ5 中編
ちょっとイロイロとあり、後編の更新ができませんでした。。。
トップ2:デグレードと納品ミス
デグレードとは、モジュール納品の際に一部モジュールを1世代以上前の古いバージョンに戻してしまうことです。つまり納品ミスですね。
また、モジュール改修時に最新モジュールではなく古いバージョンのモジュールに対して改修を加えてしまいそれを最新として納品してしまう、というパターンもあります。
現場では通常デグレと呼びます。
デグレと納品ミス、これをトップ2に置いたのはシステム屋としてすごく格好悪い失敗だと僕は思ってるからです。
最新モジュールの管理がされていない、または周知されていない、または確認が雑なために起こる事故であり、これはシステム屋云々以前の話でして、組織として大事なところが至っていない、信用に足りない事を意味していると思うんです。
一部のモジュールのみが古いということは、正常な処理がされないということなので、バグが発生します。飛行機のネジを一カ所付け忘れたようなものです。
バグの原因がデグレ。
お客様からしたら「お宅、大丈夫?他は問題ないの。本当に信用していいんですか。」となりますよ。この手のミスは言い訳ができないんです。
そして、この手のミスでは現場内で責任のなすり付け合いになる事も多いです。「あの人に確認したら最新と言ってた」とか「納品前にアナタも確認したのでは」などですね。
言った言わないで雰囲気が悪くなります。たぶん皆が悪い件なんですけどね。
デグレ以外の納品ミスとしては
単にモジュールを納品物として格納し忘れたり、お客様のサーバー上でのコンパイル漏れあるいはコミット忘れ、などがあります。
コンパイルとはプログラムソースを機械(サーバー)が認識出来る状態にしてあげること。
コミットとはデータベースのデータを更新(投入、変更、削除)をした後、その更新内容で確定させる手続き(コマンド)をここでは指します。コミットしないと更新は無かった事になるんです。このコミット忘れ、僕も過去に2度ほどやっちまったことがあります。幸い、「忘れてない?」と指摘を受けギリギリセーフだった記憶もある。
コミットする前に、本当にこの内容で問題ないかの検証を行うんです。結果問題がなければそこで初めてコミットです。万が一問題がある場合に更新はナシにしなければならない(ロールバックといいます)ので、それまでは確定しちゃダメなんです。
しかし検証に必死過ぎて燃えすぎて燃え尽きて、つい忘れる事がどうしたってあるんです。検証OKで無事仕事終了!お疲れ様でした!になる。
納品手順書といって納品の作業タスクを一つ一つ細かく書いた手順書も準備してますが、それにちゃんと書いているにも関わらずつい忘れがち。
僕の場合はいずれも納品後即座にシステムの動きをお客様に確認してもらう機会があり、そこで即発覚したので大きな問題にはならなかったのが不幸中の幸いでしたが。
もし、正しく反映されていないままシステム本番環境で処理が起動してしまうと、プログラムは反映されてるテイで処理を行いますから処理結果がめちゃくちゃになったりシステムがコケてしまいます。そうなれば僕はこの場にいなかったかもしれません。
👑トップ1:本番データ誤更新
これをやっちまったら現場は一瞬にして凍りつき、そして大炎上になります。例えるなら、マヒャドのあとにベギラゴンを食らうみたいなものです。
しかしこれは誰でもやってしまう可能性があり僕自身身近な作業でもあるので、現実味がある分、No.1にしてます。
本番データ補正とはシステム保守の作業には付き物です。システムでのオペレーションミスや、システムバグ、システムの仕様では賄いきれない部分などに対してなど、定期、臨時限らず様々な局面でデータを補正することがあります。
では本番データ誤更新についてですが、大きくわけ2パターンをあげました。
<補足>
通常システムには本番環境の他に開発環境があります。本番環境はお客様が常日頃業務で使用している環境で、開発環境とはシステム屋が補正のリハーサルや様々な検証を行ったりする環境です。もちろんお客様が検証や運用方法の確認などで使うこともあります。
【パターン1:環境の間違い】
クエリー(データの追加・変更・削除)実行を開発環境で行ったつもりが何とそれは本番環境でした。あるいは検証の為に開発環境のシステムを動かしたつもりが実は本番環境でした。
というものです。
経験の浅い人や、連日の作業で疲労困憊の人が起こしやすいです。
上記2つとも、やっちゃった瞬間を見たことありますが特にクエリーの誤実行は凄まじいかった。
開発環境のデータを本番環境のデータに入れ替えたかったようで、データ投入前に入替対象の全テーブルのデータを削除したのですが、それがなんと本番環境だった、という。本番データの全消しはなかなか経験できる事じゃないです。
やっちまったのは入社3年目の若手でした。
システム監視の一環で、データベース運用チームから「データが消された旨メールがとんで来たんだけど」と速報が入り発覚しました。
「え!?ちょっ!自分それ本番でやってんへん!?」って現場は青ざめる。静まりかえる。
・・・本番環境じゃありませんように。
一縷の望みに賭け、皆で確認します。
本番データを参照してみると確かにないはずのないデータがない。
そして実行したと言っていたデータ入替えクエリーのデータベース接続先は、バッチリ本番環境。
残念ですがこれで本番環境を消した可能性は100%、ということが判明したわけです。
不幸中の幸いだったのは、本番環境のデータを開発環境に入れる作業だったため、直前の本番環境データバックアップがそっくりそのまま手元にあった事と、業務時間外でお客様がシステム利用時間外だったためデータはバックアップ取得時から動いてない事でした。(この時点では「ほぼ確実に」であり断定できませんが)
緊急配備の上、迅速にバックアップからデータを復旧させたので奇跡的に業務にも影響を与えず事無きを得ました。
その後の障害報告会議でPMはコテンパン、そして100%復旧していることを証明するために三日三晩ほぼ徹夜でデータの照合や別アプローチからの調査裏付けをしてました。僕も近くの席で別プロジェクト中だったんですが、事態が事態だけに1日だけかり出されました。
結果的にお客様に実害は無かったものの、今回は奇跡が重なったから害が無かっただけですし、データ全消しというやっちゃった事の大きさは計り知れないものがありますので、重大インシデントとして扱われたのは言うまでもありません。
【クエリーの不備、不正】
先述のようにシステム保守では本番環境への補正が付き物です。しかし本番環境のデータをいじるのは本当に気を付けなければならないことで、何度経験しても怖いものです。
本番環境で実施するクエリーは、内容が正しいかを数人の目で確認し、このクエリーを実施しますと上役やお客様の承認手続きを経てやっと発行されます。
しかし、ここまでしても事故は起こってしまいます。
初歩的ですが補正クエリー不正の例をあげますと、キー項目を指定していなかったがために、補正してはいけないデータに対して補正してしまうものです。
キー項目とはデータベースのテーブル内で絶対に他のデータと重複しない項目をいいます。
例えば従業員情報を管理するテーブルで、項目が従業員IDと氏名と住所があり、キー項目は従業員IDとします。
そして更新対象は従業員ID:001の氏名:山田太郎さんで、住所を゛三重県゛から゛兵庫県゛に変更するとします。
ここで本来は「従業員IDが001のものを補正」とするべきなんです。従業員IDはキー項目であり重複するデータは存在しません。
しかし従業員IDを指定せず「氏名が山田太郎ものも」としてしまうと、氏名はキー項目じありませんので他にも山田太郎さんが存在する場合、全ての山田太郎さんが゛兵庫県゛に変更されてしまうことになります。
これを本番環境でやってしまい、補正対象以外の複数データが変更されてしまいデータ不整合が発生、結局不正に補正してしまったデータを一つずつ確認し、元通りに復旧させたというお話です。これももちろん重大インシデント扱いで、社内の再発防止を徹底するためのガイドラインには毎年、過去の重大事例として登場するようになりました。
やっちまった当事者などは毎年毎年蒸し返されてるようで辛いでしょうけど。
さいごに
どの業界でも絶対にやってはいけない失敗、避けなければならない失敗はあると思いますし、業界によってはそれが人の生命や人生に直結してしまうことかもしれません。
その点、我々システム業界では直接生命を脅かす類いの失敗はほぼないのですが、データやシステムというのはお客様の大切な資産ですし、この時代になくてはならないものです。
データを不正に変えてしまったりシステムバグを発生させてしまうと、「すいません間違いました以後気を付けます」じゃ済まないことが多いです。
例えば、銀行の統廃合による銀行業務システムの刷新や統合プロジェクトで、強烈なシステム障害を発生させた場合、それが例えば振り込みや引き落としが出来なくなるなど、銀行が数日機能しなくなるような障害である場合、日本どころか世界を巻き込む大混乱を引き起こし、世界経済、企業の営み、個人の生活に計り知れない程のダメージを与えることになります。
システム障害によりお客様の業務が止まってしまったり金銭面で損害を与えてしまうとなると、損害賠償問題にも発展しますし、上記のような影響範囲が広い大規模障害を発生させてしまうともはや個人や企業だけでは責任のとりようがないです。
実際には万が一にでも最後に挙げたような災害クラスの障害は絶対に起こさぬようリリースまでに何重ものチェックがされ、あらゆることを想定したリスクヘッジはされてますが、なかなかプレッシャーの多い業界ではあります。
おわり。