ゼロトラブルへの道

ゼロトラブルへの道
システムトラブルをゼロにし、ビジネスを加速させる方法

Transcript

1. ゼロトラブルへの道 システムトラブルをゼロにし、 ビジネスを加速させる方法 TOCQ： 山崎大輔（@yamaz)
2. こういうこと、あるあるです • 勢いよくクラウド上に作られたアプリがある • テストやCI/CDはあんまり整備されてない • コードの質もイマイチで結構デグレする • だけどビジネスはそこそこ回ってる • トラブルに時間取られて開発速度低下（ビジネス速度も低下） • トラブル起因で顧客をライバルに取られる • 対策はやってるものの、モグラたたき感が拭えない 2
3. システムのクオリティは超大事 1. クオリティが低いとトラブル対応のため、エンジニアはもと より関係各所の⼯数が無駄に発⽣（意味のない⼯数） 2. クオリティの低さは意味のないチャーン（解約）を産む 多額のマーケ費⽤をかけて育てたユーザをライバルにタダで取られる 3. システムのクオリティを低いと開発速度が下がる よって成⻑期においてはシステムクオリティは機能追加より⼤事 になりえる 3
4. 逆にシステムのクオリティが高いと 1. トラブルがないため、エンジニアはもとより関係各所の⼯数 がかからない（コストが低くなる） 2. 安定性はマーケ施策ともなりえる ライバルが多額のマーケ費⽤をかけて育てたユーザを奪えるチャンス 3. 気分良く開発できて開発速度が下がらない （開発速度が上がるわけではないのに注意！） 4
5. ミスやトラブルに対する考え⽅ 5
6. その前に ハインリッヒの法則 6
7. ハインリッヒの法則を3行で 1. 1つの重⼤事故の裏には29の軽微な事故があり、その裏には 300の異常が存在するという事故発⽣に関する経験則 2. だから異常を⾒逃さず対処することが⼤事 3. 対策に際しては安全⼯学の考え⽅が⼤事 7
8. 1つの重⼤事故の裏には29の軽微な事故があり、 その裏には300の異常が存在する 同じ⼈間の起こした同じ種類の330件の災害のうち，300件は無 傷で，29件は軽い傷害を伴い，1件は報告を要する重い傷害を 伴っていることが判明した。このことは5000件以上について調 べた研究により追認されている (Wikipedia: ハインリッヒの法則より） →300の異常を⾒逃してると⼤事故が起きるということ 8
9. ミスやトラブルに対する考え⽅ 1. ミスやトラブルは確率的に起きるものと考える 2. 不安定な仕組みの上に安定した仕組みを構築することは可能だ と考える 3. ミスは許容する.ただし最初の一回だけ 4. 根性論は禁止です 順番に説明していきます 9
10. 1. ミスやトラブルは確率的に 起きると考える → トラブルはありとあらゆる隙間をぬっておきるので、原因を漏れな く潰すというやり方は限界があると考える トラブルの発生回数 = 機能数＊アクセス数＊ユーザ数＊データ量*発生確率 →事業がうまくいくほど辛くなる (事業がうまくいかないと別の意味でもっと辛い） 10
11. トラブルの発生増加は複雑化の兆候 トラブルの発生回数 = 機能数＊アクセス数＊ユーザ数＊データ量*発生確率 売上 複雑性 ⼀般の⼈が考える複雑性の増加 （⼀次関数） 実際の複雑性の 増加（n次関数） 11
12. トラブルの発生増加は複雑化の兆候 複雑性増加に対してエンジニアの単調増加（一次関数）では 対抗できなくなる→開発がどんどん遅くなる真の理由 →複雑性が一定以上になると個人の頑張りではどうにもならなくなる 売上 複雑性 ⼀般の⼈が考える複雑性の増加 実際の複雑性の 増加（n次関数） 12
13. 2. 不安定な仕組みの上に安定した仕 組みを構築することは可能だと考える RAIDやロードバランサーと同じ考え方。 パーツが不安定であっても、システム全体の安定性を諦 める必要はない 13
14. 3. ミスは許容する。ただし最初の一回だ け どんなに馬鹿げた理由であっても、 そんなことを許したシステムのせいと考える →ただし必ず対策を要求し、全く同じ理由による再発は許容しない （トラブル報告自体をしないことはもっと許容しない） 14
15. 3. ミスは許容する。ただし最初の一回だ け （補足） 1. たくさんアウトプットをする人は確率的にトラブルを踏みがちなので、責めるのではなく、た またまトラブルを踏んだ人と考える 2. そうでないとトラブルを起こさないよう、何もしないという行為が個人の最適解になってしまう （それは困るでしょ？） 3. なのでむしろ今トラブルが発見できて良かったと考える 今後会社が成長するなら今回のトラブルは最も規模が小さいはず →もっとでかいトラブルになる前に発見できてよかったと常に考える（歯を食いしばりなが ら） 4. 犯人捜しに意味はない 15
16. 4.根性論は禁止です 「以後気をつけます」とか「死ぬ気で頑張ります」は基本ナシ 理由：個人の英雄的努力を永遠に期待することになり、 頑張りきれなくなったら破綻するから 頑張りはとても貴重な資源で無限には供給されない 16
17. 対策の考え方 17
18. 対策の考え方 トラブルが外部に出たら事故扱い。対策には2種類ある • 発生対策: トラブルが発生しないようにするための対策 （そもそもそんなトラブルが起きえないようにする） • 流出対策: トラブルが発生した際に外部に出ないための対策 （そのトラブルが万一おきても大丈夫なようにする） →流出対策が超大事。なのにあんまり実施されてない！ 再発防止に際してこの２種類の対策を徹底することでトラブルは激減(!!!)します 18
19. 対策の考え方 例）工場の2階から工具を落とし、頭にあたる事故が頻発するという トラブルの対策を考える • ✖ダメな方法 • 工具を落とさないように気をつける（根性論禁止） • 〇より良い方法 • 落としても大丈夫なように工具に紐を付けておく （発生対策:そのトラブルが起きえないようにする） • 落としても大丈夫なように工場内ではヘルメットを着用 （流出対策：そのトラブルが万一おきても大丈夫なようにする） 19
20. 対策は流出対策の方が 圧倒的に大事！！ なぜか？？ • 発生対策: トラブルが発生しないようにするための対策 • 流出対策: トラブルが発生した際に外部に出ないための対策 トラブルはありとあらゆる隙間を縫って確率的に発生する →よってすべての発生原因を事前に潰すことはできない →よって流出対策がとても大事となる でもあんまり重視されてない(´･ω･`) 20
21. 本当にトラブルをなくすために • 対策は必ず発生対策と流出対策の両面で • トラブルは絶対にゼロにできると心から信じ、社内に発信し続ける • 軽微以上のトラブル対応の優先度を最大にする (優先度最大というのは文字通りの意味で、対応者が他のことやってるのならその開発自体を止める） • QAがあぶり出してくれた不具合もトラブル扱いとして対処 • ヒヤリハットは必ず報告（対応は必要そうなら行う。全部は対処しない） ↑上記は前職で実際にやってたことです 21
22. 対策がしんどくなりすぎないために 22
23. 対策のための開発はしんどくなりがち • 直しにくいトラブルの存在 • 検知が改善するとヒヤリハットの発見精度があがり、対策のバックロ グが積み上がりすぎる • 積み上がりすぎたバックログの優先度付けがしんどい 23
24. 対策のための開発がしんどくなりすぎ ないためのいくつかの方法 • 直しにくいトラブルは頑張りすぎず、でも検知だけはより速く・より高 精度でできるように （ユーザに気づかれなければギリセーフ） • 検知が積み上がっていくとそれはテストのように機能するようになる ので、未来的に楽になると考える • 積み上がりすぎた対策のバックログは、今となってはそこまで重要で はなかったと考え、定期的に一旦全部捨て、今から起きたトラブルに 対して積み上げなおす 24
25. いくつか雑多なメモ 1. 機能追加なしであっても、単に売れるだけでシステムは痛みはじめる 2. エンジニアであってもこの構造は気づきにくい（のでケアが必要） 3. 機能追加は売上に常にポジティブなので選択されがちだが、マイナ スの積み上げも同時に行われてることに気づきづらい 4. なので守りの開発も重視しないといけない 5. 設計をちゃんとしてないと、因数分解しても成果が出ない 6. エンジニアは尻を叩かれても、個人だとどうにもならないと負の学習 をしてしまいがち 25
26. 最後に 正しい知識を持ってゼロトラブルな状況を作り、 システムでビジネスを加速させていきましょう！ 追加の質問などあれば Twitter: @yamaz Web: tocq.com まで 26