Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ノートラブルシステムへの道
Search
Daisuke Yamazaki
December 19, 2022
Technology
22
7.4k
ノートラブルシステムへの道
ノートラブルシステムへの道
ビジネス速度を落とさないために
Daisuke Yamazaki
December 19, 2022
Tweet
Share
More Decks by Daisuke Yamazaki
See All by Daisuke Yamazaki
RWC2019 rubyによる超大量データ配信
yamaz
0
130
学び実践してきたこと
yamaz
0
98
スケールアウト再考
yamaz
1
250
RTB 30 min
yamaz
0
67
RailsとCで広告システムを作って起業した話
yamaz
0
140
robust logprocessing
yamaz
0
33
adserver 30min
yamaz
0
44
Other Decks in Technology
See All in Technology
AI でアップデートする既存テクノロジーと、クラウドエンジニアの生きる道
soracom
PRO
2
380
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
210
Datadog を使ったプロダクトとクラウドの セキュリティモニタリング
mrtc0
0
610
Functional TypeScript
naoya
10
4.5k
ナレッジグラフとLLMの相互利用
koujikozaki
0
180
リアルお遍路+SORACOM IoT
ozk009
1
100
Monitor GraalVM Native Apps with OpenTelemetry
logico_jp
0
120
効果的なオンコール対応と障害対応
ryuichi1208
5
2.4k
Towards Effortless Transaction Management in Microservices @KubeDay Japan 2024
scalar
1
100
強いチームを夢見て-PMからSREに転身して1年の振り返り / 20240906_bengo4_sre
bengo4com
2
820
SORACOMで実現するIoTのマルチクラウド対応 - IoTでのクリーンアーキテクチャの実現 -
kenichirokimura
0
330
Eventual Detection Engineering
ken5scal
0
1.3k
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
28
1.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
103
48k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
278
13k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.4k
Building Adaptive Systems
keathley
36
2.1k
Building a Modern Day E-commerce SEO Strategy
aleyda
35
6.8k
Code Review Best Practice
trishagee
62
16k
BBQ
matthewcrist
83
9.1k
Git: the NoSQL Database
bkeepers
PRO
425
64k
For a Future-Friendly Web
brad_frost
174
9.3k
Building Flexible Design Systems
yeseniaperezcruz
325
37k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
363
22k
Transcript
ノートラブルシステムへの道 ビジネス速度を落とさないために TOCQ: 山崎大輔(@yamaz)
こういうこと、あるあるです • 勢いよくクラウド上に作られたアプリがある • テストやCI/CDはあんまり整備されてない • コードの質もイマイチで結構デグレする • だけどビジネスはそこそこ回ってる •
トラブルに時間取られて開発速度低下(ビジネス速度も低下) • トラブル起因で顧客をライバルに取られる • 対策はやってるものの、モグラたたき感が拭えない 2
システムのクオリティは超大事 1. クオリティが低いとトラブル対応のため、エンジニアはもと より関係各所の⼯数が無駄に発⽣(意味のない⼯数) 2. クオリティの低さは意味のないチャーン(解約)を産む 折⾓マーケ費⽤をかけて育てたユーザをライバルにタダで取られる 3. システムのクオリティを低いと開発速度が下がる よって成⻑期においてはシステムクオリティは機能追加より⼤事
になりえる 3
逆にシステムのクオリティが高いと 1. トラブルがないため、エンジニアはもとより関係各所の⼯数 がかからない(コストが低くなる) 2. 安定性はマーケ施策ともなりえる ライバルがマーケ費⽤などをかけて育てたユーザを奪えるチャンス 3. 気分良く開発できて開発速度が下がらない (開発速度が上がるわけではないのに注意!)
4
ミスやトラブルに対する考え⽅ 5
その前に ハインリッヒの法則 6
ハインリッヒの法則を3行で 1. 1つの重⼤事故の裏には29の軽微な事故があり、その裏には 300の異常が存在するという事故発⽣に関する経験則 2. だから異常を⾒逃さず対処することが⼤事 3. 対策に際しては安全⼯学の考え⽅が⼤事 7
1つの重⼤事故の裏には29の軽微な事故があり、 その裏には300の異常が存在する 同じ⼈間の起こした同じ種類の330件の災害のうち,300件は無 傷で,29件は軽い傷害を伴い,1件は報告を要する重い傷害を 伴っていることが判明した。このことは5000件以上について調 べた研究により追認されている (Wikipedia: ハインリッヒの法則より) →300の異常を⾒逃してると⼤事故が起きるということ 8
(あらためて)ミスやトラブルに対する考え⽅ 1. ミスやトラブルは確率的に起きるものと考える 2. 不安定な仕組みの上に安定した仕組みを構築することは可能だと 考える 3. ミスは許容する.ただし最初の一回だけ 4. 根性論は禁止です
順番に説明していきます 9
1. ミスやトラブルは確率的に 起きると考える → トラブルはありとあらゆる隙間をぬっておきるので、原因を漏れなく 潰すというやり方は限界があると考える トラブルの発生回数 = 機能数*アクセス数*ユーザ数*データ量*発生確率 →事業がうまくいくほど辛くなる
(事業がうまくいかないと別の意味でもっと辛い) 10
トラブルの発生増加は複雑化の兆候 トラブルの発生回数 = 機能数*アクセス数*ユーザ数*データ量*発生確率 売上 複雑性 ⼀般の⼈が考える複雑性の増加 (⼀次関数) 実際の複雑性の 増加(n次関数)
11
トラブルの発生増加は複雑化の兆候 複雑性増加に対してエンジニアの単調増加(一次関数)では 対抗できなくなる→開発がどんどん遅くなる真の理由 →複雑性が一定以上になると個人の頑張りではどうにもならなくなる 売上 複雑性 ⼀般の⼈が考える複雑性の増加 実際の複雑性の 増加(n次関数) 12
2. 不安定な仕組みの上に安定した仕 組みを構築することは可能だと考える RAIDやロードバランサーと同じ考え方。 パーツが不安定であっても、システム全体の安定性を諦め る必要はない 13
3. ミスは許容する。ただし最初の一回だけ どんなに馬鹿げた理由であっても、 そんなことを許したシステムのせいと考える →ただし必ず対策を要求し、全く同じ理由による再発は許容しない (トラブル報告自体をしないことはもっと許容しない) 14
3. ミスは許容する。ただし最初の一回だけ (補足) 1. たくさんアウトプットをする人は確率的にトラブルを踏みがちなので、責めるのではなく、たま たまトラブルを踏んだ人と考える 2. そうでないとトラブルを起こさないよう、何もしないという行為が個人の最適解になってしまう (それは困るでしょ?) 3.
なのでむしろ今トラブルが発見できて良かったと考える 今後会社が成長するなら今回のトラブルは最も規模が小さいはず →もっとでかいトラブルになる前に発見できてよかったと常に考える(歯を食いしばりながら) 4. 犯人捜しに意味はない 15
4.根性論は禁止です 「以後気をつけます」とか「死ぬ気で頑張ります」は基本ナシ 理由:個人の英雄的努力を永遠に期待することになり、 頑張りきれなくなったら破綻するから 頑張りはとても貴重な資源で無限には供給されない 16
対策の考え方 17
対策の考え方 トラブルが外部に出たら事故扱い。対策には2種類ある • 発生対策: トラブルが発生しないようにするための対策 (そもそもそんなトラブルが起きえないようにする) • 流出対策: トラブルが発生した際に外部に出ないための対策 (そのトラブルが万一おきても大丈夫なようにする)
→流出対策が超大事。なのにあんまり実施されてない! 再発防止に際してこの2種類の対策を徹底することでトラブルは激減(!!!)します 18
対策の考え方 例)工場の2階から工具を落とし、頭にあたる事故が頻発するという トラブルの対策を考える • ✖ダメな方法 • 工具を落とさないように気をつける(根性論禁止) • 〇より良い方法 •
落としても大丈夫なように工具に紐を付けておく (発生対策:そのトラブルが起きえないようにする) • 落としても大丈夫なように工場内ではヘルメットを着用 (流出対策:そのトラブルが万一おきても大丈夫なようにする) 19
対策は流出対策の方が 圧倒的に大事!! なぜか?? • 発生対策: トラブルが発生しないようにするための対策 • 流出対策: トラブルが発生した際に外部に出ないための対策 トラブルはありとあらゆる隙間を縫って確率的に発生する
→よってすべての発生原因を事前に潰すことはできない →よって流出対策がとても大事となる でもあんまり重視されてない(´・ω・`) 20
本当にトラブルをなくすために • 対策は必ず発生対策と流出対策の両面で • トラブルは絶対にゼロにできると心から信じ、社内に発信し続ける • 軽微以上のトラブル対応の優先度を最大にする (優先度最大というのは文字通りの意味で、対応者が他のことやってるのならその開発自体を止める) • QAがあぶり出してくれた不具合もトラブル扱いとして対処
• ヒヤリハットは必ず報告(対応は必要そうなら行う。全部は対処しない) ↑上記は前職で実際にやってたことです 21
対策がしんどくなりすぎないために 22
対策のための開発はしんどくなりがち • 直しにくいトラブルの存在 • 検知が改善するとヒヤリハットの発見精度があがり、対策のバックロ グが積み上がりすぎる • 積み上がりすぎたバックログの優先度付けがしんどい 23
対策のための開発がしんどくなりすぎ ないためのいくつかの方法 • 直しにくいトラブルは頑張りすぎず、でも検知だけはより速く・より高 精度でできるように (ユーザに気づかれなければギリセーフ) • 検知が積み上がっていくとそれはテストのように機能するようになる ので、未来的に楽になると考える •
積み上がりすぎた対策のバックログは、今となってはそこまで重要で はなかったと考え、定期的に一旦全部捨て、今から起きたトラブルに 対して積み上げなおす 24
いくつか雑多なメモ 1. 機能追加なしであっても、単に売れるだけでシステムは痛みはじめる 2. エンジニアであってもこの構造は気づきにくい(のでケアが必要) 3. 機能追加は売上に常にポジティブなので選択されがちだが、マイナ スの積み上げも同時に行われてることに気づきづらい 4. なので守りの開発も重視しないといけない
5. 設計をちゃんとしてないと、因数分解しても成果が出ない 6. エンジニアは尻を叩かれても、個人だとどうにもならないと負の学習 をしてしまいがち 25
最後に ノートラブルな状況を作り、システムで ビジネスを加速させていきましょう 追加の質問などあれば Twitter: @yamaz Web: tocq.com まで 26