Slide 1

Slide 1 text

保育園に Chaos Engineering を提案した話 Chaos Engineering for People Systems

Slide 2

Slide 2 text

Mahito Ogura < Twitter: @Mahito > 所属:イノベーションセンタ 業務:インフラ系技術調査&検証、他 ● GitOps向けの CI / CD ツール調査 ● Chaos Engineering の調査・検証 ● 分散トレーシング、OpenStack、etc… ● 社内改善、採用支援、イベント開催、etc... About me

Slide 3

Slide 3 text

今回のお話 1. 昨年、うちの子どもたちが通っている保育園から、 子供(右下図)に対するインシデントの報告を受け、 今後の対策として保育園にChaos Engineeringを提案したことと、 その後、提案がどうなったかについて 2. Chaos Engineeringを会社にどう取り込むのかについて 保育園に提案した人 ➡ インシデント被害者 ➡ 参考: - 保育園にChaos Engineeringを提案した話 - (後日談)保育園にChaos Engineeringを提案した話

Slide 4

Slide 4 text

事件はいつも突然に お昼も近い時間にスマホがなったので見ると妻からの電話 普段ならL●NE通話を使うのに、電話という時点で嫌な予感 電話に出ると半泣きの妻から 「 保育園から電話があって、避難訓練で下の子(当時 1歳11ヶ月)が・・・ 屋上に置き忘れられたって連絡があって・・・ 」 はいっ???

Slide 5

Slide 5 text

インシデントのタイムライン 1. 地震からの津波を想定した避難訓練開始 2. 保育園近くのマンション屋上への避難訓練完了、全員の無事を確認 3. アプリで避難訓練終了を保護者に通知 4. マンション屋上より階段を使って園児を降ろし帰園 5. 点呼の結果、園児が1名(うちの子)足りないインシデント発覚 6. 先生2名がマンションに戻る 7. マンション管理人が子供を保護してくれていたのでお礼を言って帰園 8. 保育園の経営母体と市にインシデントを報告 9. 保護者(妻)に園長から連絡 10. 保育園内のスタッフで話し合い事故の状況や原因、改善点について議論 11. 保護者へ謝罪と説明

Slide 6

Slide 6 text

インシデントの原因(保育園側の考察) ● 最初に泣いた子の対応に保育士の人数を割いたので、最終グループは保育士一 人に対して7名の園児(2歳前後)になり全員を目視で管理できなかった ● 誰がどの子を連れて降りたか確認をしていなかった ● 保育士の間で「誰かが手伝いに来てくれるはず」という思い込みで移動を始めてし まった ● マンションの階段を降りてから園に戻る前に点呼を怠った ● マンション屋上に園児が残っていないことを確認していなかった ● 避難訓練のマニュアルに避難訓練完了までは記載していたが帰園については記 載がなく、各自の判断で動いていた

Slide 7

Slide 7 text

 園長曰く 「避難訓練の中で園児が  いなくなることを想定していなかった」

Slide 8

Slide 8 text

「想定していなかった?  それChaos Engineeringで  対応できるんじゃね?」

Slide 9

Slide 9 text

Chaos Engineeringとは システムに対し意図的に障害を起こすことで、 障害時のシステムの振る舞いを把握するアプローチ 意図的に引き起こされた障害により問題が生じた際は、 問題を治すことでシステムをより強固なものにすることができる(Resilience) カオスエンジニアリング ≒ 疫学, 予防医学

Slide 10

Slide 10 text

Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKnown Knownsにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度

Slide 11

Slide 11 text

Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKnown Knownsにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度 Chaos Engineering Chaos Engineering

Slide 12

Slide 12 text

Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKnown Knownsにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度 Chaos Engineering Chaos Engineering Failure Testing Fault Injection

Slide 13

Slide 13 text

でもChaos Engineeringって システムに対して障害を起こすのでは?

Slide 14

Slide 14 text

Chaos Engineering for People Systems 企業を分散システムとして捉えChaos Engineeringを導入する話(by Google) ● The Wheel of Staycation - 仕事の質問や会話に関わらない ● Tortoise Time - メールなどの返信をわざと遅らせる ● Liar Liar - 質問に対して嘘を混ぜる ● War of the Worlds - 経営危機に関する情報を流す 一番複雑なのはソフトウェアやハードウェアではなく人間 人間もシステムの一部としてChaos Engineeringの対象になる 参考: - KEYNOTE: CHAOS ENGINEERING FOR PEOPLE SYSTEMS - Googleが従業員に対して実践している「カオスエンジニアリング」とは? - GIGAZINE

Slide 15

Slide 15 text

想定: 避難訓練という擬似的な障害を起こしたところ、 無事に避難訓練を終えて全員が保育園に戻ってくること 事実: 避難訓練の中で児童が一人いなくなったのに気づかず、 保育園に戻ったあとに気づき慌てて現場に戻り保護した 今回の事象

Slide 16

Slide 16 text

 Chaos Engineeringの提案 「避難訓練の中で園児が突然行方不明に  なることをやってみてはどうか?」

Slide 17

Slide 17 text

システムに対し意図的に障害を起こすことで、 障害時のシステムの振る舞いを把握するアプローチ 意図的に引き起こされた障害により問題が生じた際は、 問題を治すことでシステムをより強固なものにすることができる つまり、Chaos Engineeringは障害時にシステムが 想定通りに動くかどうかを確認することもできる Chaos Engineeringの効果 (1)

Slide 18

Slide 18 text

障害から学ぶ Chaos Conf 2019において「障害から学ぼう」というセッションが多かった Forming Failure Hypothesis [1] 1. Learn from incidents. 2. There is no lesson 2. Hot Recipes for Building Chaos Experiments [2] “The best time to learn about fire is when you’re on fire. “ [3] Chaos Engineeringの効果 (2) [1]: https://speakerdeck.com/chaosconf/forming-failure-hypotheses?slide=31 [2]: https://speakerdeck.com/chaosconf/hot-recipes-for-building-chaos-experiments?slide=12 [3]: https://blog.newrelic.com/engineering/how-to-run-a-game-day/

Slide 19

Slide 19 text

Chaos Engineeringの副次効果 (3) 過去の障害体験と検証 Think Big: How to Chaos Test a Monolith [1] Chaos engineering is an effective tool for sharing knowledge and building empathy. Gremlin の Scenarios [2] という機能は過去の障害をシナリオ再現可能 Game Days という障害を疑似体験から学ぶものもある [3] [1] https://speakerdeck.com/chaosconf/think-big-chaos-testing-a-monolith?slide=117 [2] https://www.gremlin.com/docs/scenarios/overview/ [3] https://speakerdeck.com/yurynino/automating-chaos-engineering-gamedays-with-terraform?slide=16

Slide 20

Slide 20 text

● 避難訓練のマニュアルに帰園までのマニュアルを追記 ● 保育士一人あたりで対応する園児の数を設定 ● 点呼のタイミングをマニュアルに記載し、点呼の際は保育士2名以上で確認 ● 屋上から園児を連れて降りる際に、連れて降りる園児の名前を声に出す ● 責任者2名がマンション屋上に園児が残っていないことを確認 提案は採用されませんでしたwww ※1: これはこれで突っ込みどころがあったので個別にツッコミさせてもらいました ※2: 後日、妻から友達の中学校では避難訓練時に生徒1名が先生に拉致されて気付けるかをやってたと聞いて驚いた 保育園側の改善案

Slide 21

Slide 21 text

まとめ Chaos Engineeringは ● 新しい情報を作り出すためのアプローチ ● 問題の確認、学びの場、ナレッジを共有する方法 ● ITだけでなく人間も含んだ広い意味でのシステムに適用可能