  |
運用監視の現場で週末も心休まらない皆さんこんばんは。一人運用チームです。
さて、世間ではDevOpsだのイケてるクラウド監視ツールだの楽しそうですが、そうでない人もいますよね。
もちろん、「運用チーム（実態は俺1人）」なんてのは、ペイグレードに応じた責任感で粛々と業務を進めて理不尽には応じないのがプロフェッショナルな態度ですが、
お銭を稼がなければ生きていけないのも渡世の世知辛いトコロです。
これから金を生むんだ！という強烈な人間が金を引っ張ってこない限り、コスパの悪いサービスにリソースは割り振られません。
つまり、今もし運用監視体制が限界ギリギリで踏ん張っている場合、拡充される可能性はありません。諦めましょう。
今回のみずほ銀行の調査報告書（2021年6月15日発行分）p114-p116におけるヒアリング結果が悲哀に満ちているのも当然と言えるでしょう。
教訓は、「維持メンテの人員が不足したら、それ以上増えない」というものですね。
維持されている（ように外部から見える）場合、余剰人員は不要なコストです。
さて、みずほ銀行の調査報告書を読むと、今回大ごとになっている「通帳の取り込み」というのは何度か起きていますが、改善されていません。
まあ、やりたくないよね、「障害が起きた時の顧客影響を抑える」なんて後ろ向きな投資。
なお、盛大な怒られが発生した結果、再発防止策として、今回の通帳取り込み5244件のうち4915件をなくせる仕様変更が入りました。
直せないのではないのです。直さないのです。
教訓は、「障害が発生しても、予算を握ってる人に被害が及ばない限り、リソースは降ってこない」というものですね。
過ぎたことは過ぎたこと。いま維持メンテがギリギリのところに新たにリソースが投入されることは基本的にありません。
外圧があれば別ですが。
さて、ここまででわかる通り、いま1人運用やそれに近い運用をしている皆さんに、追加人員は来ません。
リソースは降ってきません。予算は通りませんし、人員は増えませんし、なんなら残業代も出ません。
もうわかりますね？障害は握りつぶしましょう。出しても一つも良いことないんですから。
慢性的に時間がない皆さんに朗報です。実は時間を生む画期的なテクニックがあります。
業務について最初に、毎日1時間を「斧を研ぐ時間」にするのです。
大丈夫分かっています。今あふれんばかりに仕事があって実際あふれているんでしょう？
どうせあふれるんです。あふれさせましょう。どうせ怒られるなら「仕事」したいじゃないですか。
WARNINGやERRORまみれのログが定常的に出ている状態は、たいへんよろしくないです。
握りつぶしましょう。
「そのエラーは概ねもっと深刻なエラーが吐かれるまでは気にしなくて良いヤツ」みたいなのがあるでしょう？
消し去りましょう。痕跡すら残さずに。
そのために、運用監視用のログが必要なら、生成しましょう。その生成途中で握りつぶせば良いのです。
「ドラえも～ん、大量にエラーが出たら処理しきれないよ～」「のび太君それ全部処理するの？」「え？」「え？」
当たり前のことなんですが、人間には概ね4本以下の手しかありません。俺は2本派です。
運用チームの対応者が一人の場合、対応できる時間当たりの処理能力には上限があります。人間はオートスケールしないんで、当たり前ですね。
つまり、「同じようなエラーで同じような処理をしないといけないが、違うエラーメッセージ」というのは、無意味です。
さっき、自分が理解ってるエラーを握りつぶすことを日課にしましたね？
次の段階です。対応できるエラーだけ残して握りつぶしましょう。
もちろん、裏では垂れ流しで大量のエラーログは取っておく必要はあります。見るエラーは一つで良いはずです。だってまずそれ対応するんだもの。
例えば、1人の時に100件のエラーが出ても、3人の時に6000件のエラーが出ても、処理できないことに変わりはありません。
つまり、それは「記録には残すエラー」ですが「対応のトリガーにするエラーメッセージ」じゃ無いんです。
例えば、幸せなことにショートメッセージやメールに自動発砲できる場合、初手だけ発砲して残りは握りつぶしましょう。
飛行機や宇宙船で機長が言うでしょう？事故が起きてアラーム鳴ってたら、アラームを切れって。
アラームは気が付かないと困るからワーワー言うんであって、処理してる最中は邪魔なだけです。
握りつぶしましょう。
多少手荒でも良いんです。エラー即再起動みたいな乱暴な奴でもオッケーです。
思い出してください。リソースは無く、対応するのはあなただけ、維持管理出来て当たり前。
どうせクレームの電話がかかってくるなら、一人一人に真摯に向き合って丁寧に応対するのも良いかもしれません。
身命を賭してクレームに寄り添って慚愧に堪えぬその思いを真剣に伝えましょう。
その間に、システムは自動的に再起動し、他のクレームの電話は保留音を聞くことに飽きてきます。
慣れてくると、鼻をほじりながら「誠に申し訳ございません、今誠心誠意全力で復旧に」と喋りながらチャートを引っ張り出して手順を追えるようになります。
復旧手順RTAチャートの作り方は、珍しく潰しの効く能力になるので磨きましょう。
しっかりとしたチャート、常にチャートを見直す向上心、日々の走り込み、本番での平常心。
出てきたモグラを叩くのではないのです。モグラの出現順序を覚え、練習し、効率良く叩くのです。
さて、最近も陰謀が話題になりましたが、情報を知るものが増えれば握りつぶすことは難しくなります。
人を減らしましょう。
レポートラインは一本に絞り、その障害が起きたことになると給料が下がるタイプを相手に連絡を取りましょう。
うっかりミスからメールのCCから落とすのでも、手順書を作ったときに気が付いたら項目が無くなっていたのでも問題ありません。
残念ながら、その時不思議なことが起こって、連絡先が増えることもあるかもしれませんが、そういう時も諦めましょう。
出来ることは変わりません。
みずほ銀行の場合、A2以下の障害ランクの場合、頭取は別にニュースで初めて情報を知っても良いのです。
システム障害というから、なんか大変なことになるのです。インシデントだの障害だのは無くしましょう。
それは「予定されていた手順」なのです。
納品されたハードウェアには不備があり、雷は落ちてコンセントまで到達し、ケーブルは間違えて刺さり、ココしかないというタイミングで停電になります。
ただでさえ維持メンテの人員が足りてないのに追加機能や新規バッチが走ったりすることもあるでしょう。
チャートです。RTAチャートです。復旧RTAチャートを作るのです。
そのチャートには不足しかないかもしれません。ハードウェア故障→上司に電話、停電→上司に電話、みたいなチャートもよくあることです。電話しましょう。
それは障害ではありません。事前に探しておいたルートを走る競技です。
李下に冠を正さず。
例えカンムリが傾いてると分かっていても、問題になりそうな場所で手をあげてはいけないのです。
繰り返しになりますが、ペイグレードに応じた態度がプロフェッショナルには求められるのですが、お給料はいただきたい。
必要なのは、まず個別最適化です。あなたの仕事を減らしましょう。
余裕が生まれたら「この仕様は修正した方が」とか「週末にバッチあてるなら前の週末に復旧訓練をしましょう」とか言い出せば良いのです。
まあ、次にみずほ銀行が日曜に新規バッチを当てるときに、その2週間前の日曜に頭取を含んだS懸念の緊急対策本部を立てた訓練をするかっていうと、しないんじゃないかな。
つまり、そういうことです。
我々は、日々斧を研ぐ時間を作り、RTAチャートの更新を怠らないようにしましょう。
こうしてイタリアのロープウェイは超加速で後戻りして行ったのでした チャンチャン
10
