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
21
7.1k
ノートラブルシステムへの道
ノートラブルシステムへの道
ビジネス速度を落とさないために
Daisuke Yamazaki
December 19, 2022
Tweet
Share
More Decks by Daisuke Yamazaki
See All by Daisuke Yamazaki
RWC2019 rubyによる超大量データ配信
yamaz
0
100
学び実践してきたこと
yamaz
0
66
スケールアウト再考
yamaz
1
220
RTB 30 min
yamaz
0
44
RailsとCで広告システムを作って起業した話
yamaz
0
97
robust logprocessing
yamaz
0
19
adserver 30min
yamaz
0
25
Other Decks in Technology
See All in Technology
大規模言語モデル (LLM)における低精度数値表現
pfn
PRO
3
840
20240509 CloudWatch でいろいろなものを監視してみよう
masaruogura
1
120
TailwindCSSでUIライブラリを作る際のハマりどころ
shuta13
0
230
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
170
エムスリーマルチデバイスチーム紹介資料 / Introduction of M3 Multi Device Team
m3_engineering
1
170
社内での継続的な機械学習勉強会の開催のコツ
yudai00
2
390
AWS CLIの起動が重くてつらいので aws-sdk-client-go を書いた / kamakura.go#6
fujiwara3
6
3.4k
生成AIと産業向けソフトウェアの自動生成 〜 ハノーバーメッセ2024より〜
kioto
2
430
Security Hubのセキュリティスコアはどうやって計算されるか
toru_kubota
0
100
テストコードを書きながらCompose Multiplatformを乗りこなす
subroh0508
0
150
OPENLOGI Company Profile for engineer
hr01
1
2.2k
拓展QA日常工作的邊界
line_developers_tw
PRO
0
590
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
217
8.6k
Optimizing for Happiness
mojombo
370
69k
Typedesign – Prime Four
hannesfritz
36
2.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
123
39k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
20
1.8k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
323
20k
How to Ace a Technical Interview
jacobian
273
22k
Bootstrapping a Software Product
garrettdimon
PRO
302
110k
We Have a Design System, Now What?
morganepeng
43
6.8k
Scaling GitHub
holman
457
140k
The Language of Interfaces
destraynor
151
23k
[RailsConf 2023] Rails as a piece of cake
palkan
29
4.1k
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