エンジニアがシステム障害と向き合う（Ver.2023下半期）

いくつになっても、第一線の現場から離れても、やはり逃れられませんね。障害。自分が引き続きこれからどう向き合っていこうかの考えを巡らせる中で、他の方からどんなFBが返ってくるのかを見てみたいと思い、まとめてみた備忘を公開します。昨年公開したものからさらに、組織についてインプットしたものを加筆してのバージョンアップです。

当人の心持ち

障害（バグ）は出したくない

当たり前ですが、出したくて出してる人なんて全くもっていません。ついでにいうと、出してもいいやと思っている人も全くいません。本当に見たことはないです。しかし、障害はでる。そう、強いて言うのであれば、「出したくないので有効な施策を講じていない人」はいます。あしからず。

手を抜いたつもりもない

障害を出してしまった当の本人は、確認をおろそかにするつもりもなければ手を抜いているつもりもありません。一生懸命自分に思いつく限りの確認をしているのです。強いて言うのであれば「思いつく範囲や切り口が少ない人」はいます。あしからず。

でも後悔している

障害を出したいなんて思ってもおらず、手を抜いているつもりもない、しかしそれでもなお、バグを出して後悔しない人もいません。
「あのときああしていれば」
「あのときは気づかなかったけれど、翌々考えてみれば確認して当然では」「今度からここは気をつけよう」
というむやみな思考がひたすらに頭を駆け巡ります。強いて言うのであれば「後悔した後に、自動的に発動する再発防止システム」を設けることをしない、反省をしない人はいます。あしからず。

あしからず、な人とそうでない人の言葉

あしからず、という表現をしてみたこともあり、ここで個人的に少しだけまとめます。

「ちゃんと○○する」という人と、「○○できないかもしれない」という人

→　私は『ちゃんと』という言葉は次のアクションに対して定義不可能なためあまり好きではありません。バグと向き合うときにはNGワードと捉えます。

次こそは○○するためには」という人と、「二度と○○しないためには」という人

→　『次は』という言葉を使うと、どうしてだかわかりませんが、『次の次』を想像してしまう自分がいます。そして『次の次』でなんとかできると思う、と甘えてしまう自分がいます。なので使わないことにしています。言うならば、『二度としない』という言葉を使ったほうが、真剣に向き合う覚悟が決まります。

「想定が『甘かった』」という人と、「○○を想定していなかった」という人

→　「甘かった」の言葉で済ませてしまう時は、どこに問題があったのかの掘り下げから逃げてしまったときかもしれません。何かを特定して「想定してなかった」というと、「他にもないだろうか」と不安になって最後まで探してくれる自分がいると感じます。

その姿勢が、「誰か助けてくれ」という学びの渇望につながる

少々大げさなモノ良いですが、ここまでいって始めてようやく「自分だけではどうにもならない、誰かの助けが必要だ」「どこかの誰かから学びたい」「きっと解決した人間がいるはずだ」につながるのでしょう。

そこでようやく、「監視」「テスト」「QA」「SRE」「DevOps」先人たちの様々な戦いの痕跡の価値を知り、我が身として吸収していくことになるのだろうと。

障害（バグ）と『向き合う』とは

そうして戦っていくことが「向き合う」なのだろうということなのだとは思いますが、やや抽象度が高いのでまとめとして、「向き合う」という言葉にも認識しやすいよう具体的なアクションを添えておきたいと思います。

どれだけ「目に見える」アクションプランを、
どれほど「たくさん」、
どれだけ「明瞭に書き起こす」か。
障害と「向き合う」ということはそのためにどれだけの時間を注ぐことができたか。

当然のことのように見えますが、「改善策」をいざ実施しろと言われたときに、満場一致のアクションが取れる策になっていることも、また稀であるといえます。

１つ２つの「改善策」では失敗して通用しないかもしれません。

自分自身だけでなく、仲間たち、そして未来の仲間たちの身を案じて伝わるよう書き記してこそなはずです。

エンジニア「組織」がシステム障害と向き合う

ここまで、個人の振り返りに焦点を当てていましたが、今年の大きな気付きとしては「個人としてできることには限界があり、組織として、そして業界として紡いで行かなければならないのが『システム障害との向き合い方』であるな」というところです。

航空業界の話。

https://amzn.asia/d/ceb0NwA

失敗の科学という本で、２つの航空事故の記事を読みました。１つは住宅街への墜落、１つは川への着水。前者のパイロットは非難を受け、後者は称賛されていたそうです。

印象的だったのは、前者の墜落事故は1978年、後者の着水は2009年の出来事であり、後者のパイロットが称賛されたときのインタビューとして回答した言葉。

我々が身につけたすべての航空知識・ルール・操作技術は、どこかで誰かが命を落としたために学ぶことができたものばかりです。
大きな犠牲を払って、文字通り血の代償として学んだ教訓を、我々は組織全体の知識として、絶やすことなく次にお世代に伝えていかなければなりません。
これらの教訓を忘れて一から学び直すのは、人道的に許されることではないのです。

人間の認識力やコミュニケーション能力についての理解の浅さ、システムやオペレーションへの潜在的な問題、そうした事故の要因は個別のものではなく「業界としての見識や積み上げの浅さ」によるものだった。

恥を顧みず、痛みを恐れず、失敗を赤裸々に公開し、それを咎めず、全員が次に繋げるために身に刻んでいく、そうした姿勢で失敗から学び紡いだことによって、今日の成功があるのでしょう。

IT業界の話。

「ITバブル」という言葉が生まれておよそ20年超、まだ出来上がったばかりの未成熟なソフトウェア産業は、各所で事故が起き、中の人間が痛みを伴いながら課題に向き合っているまさに渦中と言えます。

であるならば、自らの失敗は、明日の誰かのために、公開していきましょう。

そしてそのために、失敗を咎めず受け入れるという覚悟を業界全体として持っていきましょう。

それが20年後ソフトウェアに関わる人を幸せにするに違いありません。（と、信じてやらなければ救いがないですね）

おしまい

バグを出さずに開発したい

バグを出しても問題ない環境を作りたい

人ではなくバグに向き合う文化を作りたい

言うは易しで宣うばかりになってしまいがちな我々エンジニアではありますが、せめてせめて、まだ見ぬプレイヤーたちが納得した仕事をできるよう、心がけだけでも時たま胸に留めておきたいものです。