社内イベントを成功させるために
kurochan
デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
しくじり話の共有会を開きました
doiken
しくじり話とは
こんにちは。土居です。
当社では業務で何らかの失敗を起こしてしまった時に、「しくじり話」としてドキュメント化しています。失敗をチームメンバー間で共有することで、似たような失敗を極力起こさないように努めています。
弊社ではこの取り組みを非常に重要視しており、長期間継続しています。
確認すると最も古い「しくじり話」は2015年のものでしたので、制度化されてから7年が経過しており、様々な「しくじり話」がありました。
通常、失敗はできるだけ起こしたくないものだと思いますが、あまりに失敗が少ないということはそもそもチャレンジができていないとも考えられます。そのため積極的な目標が設定されることの多い全社の四半期目標の一つに「しくじり話」の数を増やすことが設定されたこともあります。
「しくじり話」については過去にも何度か取り上げていますので、興味のある方は是非ご一読ください。
※過去のしくじり話に関する記事
10日間 で AWS Lambda 関数を 28億回 実行した話
しくじり話の共有会
このように長期に渡って継続している「しくじり話」の制度ですが、その共有に関しては他のドキュメント同様に各自必要に応じて/興味を持ったら読む。といった形が取られてきました。
今回、私の「しくじり話」が特に他のプロジェクトでも似たような問題が起きかねないものなのではないか、と判断され、時間枠を設けてプロジェクト関係者・それ以外のメンバーも含めて共有会を実施しました。
失敗の概要
今回のしくじり話の元ネタとなった失敗はどのようなものだったのか、かいつまんで説明いたします。
まず、あるコンテナで稼働しているWebアプリケーションの本番ワークロードにおいて、一部機能が全く動作しなくなる障害が発生しました。原因を調査したところリソースの逼迫に起因するものであることが分かり、解消するにはインフラストラクチャの設定変更の必要がありました。
その後、ステージング環境で適切な設定変更手順を検証した上で、手順書を作成して本番環境への作業に臨みました。
しかし、手順書から必要な手順が抜け落ちていたために不十分な作業実施となり、目的の設定変更が有効とならなかった。。というものでした。
ステージング環境での検証時では正しい手順を踏んでおり、設定も有効になっていたため、凡ミスともいえますが振り返ってみるといろんな原因が考えられました。
振り返り
直接的には、せっかくステージングで検証した手順をそっくりそのまま手順書に反映できていなかったことが原因だと思います。
その回避策としてはしくじり話共有会で以下が挙げられました。
$ historyで実際に打った手順を確認する$ script -aで操作ログを出力（※コマンド自体知らなかったので勉強になりました）- 手順全体をスクリプト化し、実行するだけにする（可能かつコストが見合う場合）
また、
- 複雑と考えられる作業は検証時にペア作業を実施する
- 完成した手順書を元に、改めて検証環境で作業を実施する。
といった対策も挙げられました。
また、振り返りには「なぜなぜ分析」※が良いという話もあったため実施してみたところ以下のような原因も思いつきました。これはまだまだ深掘れると思います。
※ ある問題の要因からさらにまたその要因を起こした要因は。。？と繰り返していくことで、より深い要因をあぶり出し、対策の有効性を検証すること
- 検証によって完全に理解した（と思っていた）ために、実際の操作そのものではなく記憶を頼りに手順書を作ってしまった。
- 比較的単純な手順であるという思い込みがあった。
- 対象のツール(今回はDocker、特にdevice mapper)についての理解不足があった。
様々な観点についての議論
本件の「しくじり話」としては「手順書への記載漏れ」という問題になりますが、合わせてアプリケーション/インフラ設計によってこの障害自体を起こさない方法は取れたのか？といった議論や、
対象のコンテナリソースについての監視ができていなかったためユーザの問題発生まで気づけなかったこと、などそもそも障害が起きてしまったこと自体の原因についても話が広がっていき、大変有意義な共有会となりました。
まとめ
当社では暗黙知の属人化防止や、業務経験の共有を目的として「しくじり話」に限らずドキュメント化を推進しています。作成されたドキュメントは都度Chatツールに通知され、そこでチームメンバーは気づくことができますが、特に共有したい・意見が欲しいものについては時間を取って議論をしていきたいと思います。
AUTHOR
