Brian Troutwine氏はDevOps Days Belgiumで複雑なリアルタイムシステムや人間とマシンのインタラクションについて発表した。
リアルタイムシステムは可能な限り速く動くだけでなく、デッドラインがある。システムを分類すると以下のようになる。
- 柔らかいシステム。デッドラインをすぎると結果の使いやすさが劣化する。
- 固いシステム。頻度の低いデットライン超過には耐性があるが、システムのサービス品質は劣化する可能性がある。
- 堅いシステム。デットラインを超過するとシステムは完全に障害を起こしてしまう。
一般的に、複雑なシステムは、次の性質を持っている。
- 非線形なフィードバック。
- 外部システムとの結合。
- モデル化が難しい。把握が難しい。
Brian氏は人間とマシンのインタラクションについてふたつの視点から説明する。人間とマシンが協力する場合と対立する場合だ。それぞれ、アポロ13とチェルノブイリ原子力発電所事故を例示している。
NASAの宇宙ロケット計画は人間とシステムをどのように調和させるかについて理解ができていなかった。完全に自動化されたロケットを開発するという実験があり、そのロケットはエンジニアの理解に従うだけだった。しかし、宇宙飛行士たちは違う考えを持っていた。彼らはテストパイロットだったため、ロケットをより精巧にできた飛行機だと考えていた。従って、システムは人間とコンピュータで制御できるように設計されており、バランスは取れていると考えていた。アポロ13の事故のとき、宇宙飛行士たちの問題を特定してシステムを調整するという専門知識が彼らの命を救った。
ツールは専門家が困難を克服するのを支援してくれる。
- 正しく行われた自動化は退屈を緩和する。
- 正しく行われた自動化は失敗を少なくする。
- 正しく行われた自動化は自由を生む。
チェルノブイリの事故では、システムは障害が発生すると大惨事に向かってしまうという設計になっていた。バックアップシステムのテストの最中、リアクタは障害を起こしやすい状態になり、設計と管理不足によって、警告のサインは無視された。さらに、重要な装置が利用できない状態だった。ロックされていたからだ。この環境では、人間は信頼されていないので、リアクタは自然と障害を起こしてしまう。機械を制御できずに、死者多数、ウクライナの一部が完全に放棄される結果となった。
- 自動化は正しく行われないと人間を機械にしてしまう。そのような自動化は人間に何も情報を与えない。
- 自動化は正しく行われないと方向を間違える。正しい情報を取得しない。
- 自動化は正しく行われないと罠に陥る。
あらゆるシステムはそれぞれ固有の崩壊原因を抱えている。"普通の事故"を避ける方法はありません。障害は避けられません。システムの設計は障害を織り込むべきです。そうでなければ、障害は全くの気まぐれで発生してしまいます。
複雑なシステムを設計するときは、人間の失敗を認識し、自動化することで補う必要がある。ひとりで仕事をするのではなく、暗黙のバイアスを避け、他の人の観点を理解する必要がある。
- 犠牲にできるリソースを持つこと。
- 障害を受け入れ、学習すること。
- ほかの人の事故から学ぶこと。
- 失敗のコストが高すぎるが故に構築する価値のないものもある。
- 何を開発するのか理解すること。
講演はDevOps Daysの2日目に行われた。1日目の発表の要約はInfoQで読むことができる。