DevOpsのテキスト研修
DevOpsの継続的な学習をどう実現するか
ソフトウェアプロジェクトの経験から、チェックリスト、ピアレビュー、統制、監査、コンプライアンスの仕組みを設けても、問題は起こるとわかっています。避けられないことです。DevOpsチームと組織に、自分たちで問題を診断し、学び、改善する文化を作るときです。問題が起こることを受け入れ、起きたときにチームが対応できるよう備えます。問題解決は、例外的な作業ではありません。組織が学び、改善し続けるための日常業務です。解決策を組織全体で見えるようにし、利用可能にして、簡単に参照できるようにすると、その効果をさらに広げられます。
有力なDevOps組織の一つであるNetflixは、クラウドベースのデータセンターで重大な障害をシミュレーションする社内ソフトウェア、Chaos Monkeyを作りました。Chaos Monkeyは本番システムのサーバーを無作為に停止させ、チームが、障害に耐えられるか、安定性を保てるか、顧客に質の高いサービスを中断なく届けられるかを、さらに確かめられるようにします。障害のたびに新しい教訓を得て、システムの安定性と回復力をさらに高めています。
学びの文化を築く重要性を理解する
インシデントの後に責任を押し付け合うと、エンジニアが萎縮する文化が生まれます。エラーから意識して学び、組織として自然にエラーに強くなり、より注意深く予防できるようになる代わりに、仕事は遅く、手続きは煩雑になり、社内政治に振り回されます。皆が自己防衛を優先し、仕事も問題も解決策も、十分に見えるようにはなりません。
Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so
- ミスを減らすため、仕事の量を減らします。
- 仕事、問題、解決策を明らかにしなくなります。
- 問題の解決策を組織の学びに変える動機が失われます。
- 誰も問題と解決策について学び、共有し、教え、見えるようにするために時間と労力を使わないため、同じ問題、あるいは非常によく似た問題が必ず起きます。
インシデントが起きたら、原因についての記憶が薄れる前に事後検証を行う
事後検証の目的は、次のようにシンプルです。
- うまくいった対応を特定し、似た状況で再び試せるようにする。
- 別の対応を取るべきだった点を記録し、今後の手法を改善する。
- 誤っていた対応を記録し、同様の問題が次に起きたときに採るべき別のアプローチや安全対策を提案するため。
- インシデントの原因となった行動を取った、または取らなかったことが、当時はなぜ合理的だったのかを明らかにするため。
何を間違えたか調べるのは怖いことで、組織によっては危険でさえあります。ミスを認めると非難や処分を受けるなら、誰も認めようとはしないでしょう。過去のミスを理解できなければ、通常は同じミスを繰り返すため、このやり方は結局、目的に反します。改善に真剣な組織はこのことを理解し、安心してミスを検証できるプロセスと文化を、手間をかけて築きます。
事後検証を始めるにあたり、次の前提を受け入れる必要があります。
- 誰もが、自分が理解している状況の中で、最善を尽くそうとしています。
- 判断は、プレッシャーのかかる状況で、不完全な情報をもとに行います。
- 訓練を受けていない作業を、その場にあるツールやリソースで行うよう求められることがよくあります。
- そうした状況では、ミスは避けられません。
- このプロセスの目的は、個人やその行動の落ち度を見つけることではありません。何が起き、そこから何を学べるかを確かめることです。
- このプロセスで評価するのは個人やグループではなく、仕事のプロセスと、どのように改善できるかです。
関係者全員が、次の考え方を完全に受け入れることが不可欠です。「誰も責めない。ここに集まったのは学ぶため。」多くの組織が、このような安全な環境を作るために尽力しています。たとえば米国連邦航空局（FAA）の航空安全報告システムでは、「ミス」を犯したパイロットがインシデントを報告すると、規制当局による処分を免除される場合があります。
事後検証では、インシデントの再発を防ぐため、実行できる対策を必ず定めます。たとえば、新しいテレメトリのメトリクスや自動テストケースの追加、追加のコードレビューを必要とする変更の種類の特定、頻繁に問題を起こすコードのリファクタリングや複雑なシステムコンポーネントの疎結合化です。
事後検証の記録と教訓を組織内で広く共有します。バリューストリームの一つの工程で得た学びを、組織全体の知識に変えられます。透明性、開かれた姿勢、学びを大切にするという、DevOps組織への明確なメッセージにもなります。
システム改善のためにゲームデーを開く
ゲームデーは、外向的な人だけが楽しみ、内向的な人は早く時間が過ぎるようにスマートフォンをいじる、いつもの退屈なチーム行事とは違います。
ゲームデーでは、テストシステムで重大な障害をシミュレーションします。DevOpsチームが障害を修正し、そこから学びます。
たとえば、重要なサーバーを停止させ、サービスを中断せずにフェイルオーバーが機能するかを確認します。その後、バックアップまたはインフラストラクチャのコード化（IaC）からの復旧の仕組みが、機能するか、どのように機能するかを検証します。こうした障害シナリオで問題を見つけると、障害に強く、耐障害性のあるシステムを作り、教訓を得られます。
問題に対処する過程で、DevOpsチームは切迫していない状況で障害対応を練習しながら、他の部門との関係を築きます。より大きなグローバル組織全体のコミュニケーションとトラブルシューティングのプロセスを試し、改善する機会を具体的に得られます。
さらに、将来現れるかもしれない、より大きな問題のかすかな兆候を観察できます。障害シナリオで優先度の低いインシデントが頻発したり、小さな副作用が別の重要なコンポーネントをクラッシュさせかけたりすることがあります。こうした兆候を見逃さず、原因に対処してシステムを改善しましょう。
まとめ
DevOpsチームでは、見通しを立てたうえでリスクを取ることを促します。あなたの組織のように高い成果を上げるDevOps組織では、エラーをより頻繁に経験します。それは許容できるだけでなく、学び、より良い成果を上げるために必要なことです。
高い成果を上げる組織では、一般的な組織より本番システムの重大な障害が80%少なくなります。つまり、顧客に影響するインシデントは5分の1です。DevOps組織のエンジニアが、ミスを恐れずに学べるようにすべき理由です。
