システム障害との向き合い方 @sinamon129 #tokyogirlsrb

これまで大小様々なシステム障害に遭遇してきましたが、障害対応から学ぶことは沢山あります。
いろんな習熟度のフェーズで障害発生を学びに変えるための行動事例や、webアプリケーション開発において障害対応を減らすためにできることなどをお話しできればと思います。

TokyoGirls.rb Meetup vol.1
https://techplay.jp/event/716251

Transcript

1. システム障害との向き合い⽅ !TJOBNPO
2. ⾃⼰紹介 RiLi, inc. 取締役 CTO RailsGirls Tokyo 5-11th coach          7th organizer ͠ͳ΋Μ @sinamon129
3. 登壇内容を決めた経緯 • りさきゃん⽒からの要望 • 「個⼈的にはしなもんちゃんにごりごりテックな話をし てもらいたみ！！」 • いつもtechの中核を避けたような発表しかしてない • 特にOSS活動とかしてない（仕事が趣味みたいな） • これまでのエンジニア⼈⽣でインパクトがあったもの
4. 前提⽂脈 • ⾃社プロダクト・C向け • 同じプロダクトを作るエンジニアは1 ~20⼈ぐらい • 仕様設計・開発・テスト・リリース・運⽤全て • いわゆるwebアプリケーション開発 • クラウドインフラ〜バックエンドまで
5. 「システム障害対応」 を やったことある⼈？✋
6. どんな種類のシステム障害があるか • 開発時の実装ミス（バグ） • ⼿動操作のミス • アクセスがドッカン • 使ってるサービスの不具合 • など、これらの単⼀もしくは複合
7. システム障害対応とは 提供サービスが 「期待しない状態」に なっている時の対応
8. 障害が起きてから収束するまで • （発⽣） • 発覚 • 調査 • ⼀次対応 • 収束 • ふりかえり（＆恒久対応）
9. エンジニア⼈⽣において 障害対応で学んだことが 多い
10. ⾃分のフェーズ別 障害対応
11. • あくまで私の経験。⼀例として。 • どういう⾵に障害対応と触れ合ってきたか • 「障害対応⾃分以外誰もできない」っていう相談に乗る ことがなぜか多いのでその辺の話にも触れます
12. 障害対応と深夜対応はすごい⼈がやるとおもってた期 • 社会⼈1年⽬ • (当時)10年物のサービスの部署に配属 • ウェブアプリケーションエンジニア20⼈ぐらい • なかなかに⼤きなコードベース • エラーがメールで⾶んでくるがどうしていいか分からない • ⾃分がバグを仕込んだと指摘された時以外何もできず
13. 障害対応と深夜対応はすごい⼈がやるとおもってた期 ベテランの⼈たちが対応してる、すごい 興味はあるけど分からなさそう ⾃分の仕事で精⼀杯 深夜メンテナンスって何やるんだろう
14. 初⼼者期
15. 状態 • 社会⼈2年⽬（転職して前職に） • ウェブアプリケーションエンジニア6⼈ぐらい • 「1⼈でどうにかできる状態」に早くなるのが⽬標 • できないことを減らすために奮闘
16. 障害発⽣させてしまうと焦るけど • （しなもん）＜ やばいどうしよどうしよ あばばば • （せんぱい）＜ しなさん焦りすぎ・とりあえず落ち着いて。 何をしたら何が起きたの？ • 先輩にしゃっと⾔われて冷静になるなどした • 焦るけど冷静になって対応した⽅が早く解決する • 落ち着いて⾒えるように⼼がけたら落ち着けるようになった
17. 分からなくても参加する • （Slackにアラートがくる） • （しなもん）＜ おっアラートだぞ • （先輩たち）＜ これはxxxが原因かもですね • （しなもん）＜ 今何を⾒て⾔ってますか？ • 何か起きた時にどこを⾒ればいいか・どう問題を切り分け ればいいかを学んだ
18. 急がなくてもいい部分を担当する • ⼀次対応（とりあえずの復旧）が終わった後に障害報告 を書いて、根本解決をしたりすることがよくある • 発⽣原因を踏まえて次に起こらないようにする仕組みづ くりの部分をやらせてもらう • ⼀分⼀秒を争わないが、問題の近いところを理解でき る
19. 先輩より早く原因特定するゲームを実施する • 脳内実施 • まず発⽣に最初に気づけるようにする • ⼿がかりになりそうなことを話し合いながら解決の⽷⼝を 集中して探す • ベテランの先輩より早く⾒つけられるとちょっと嬉しい • 何回もやってると段々切り分け⼒が上がる
20. やったことがないことに触れる • （せんぱい）< そろそろxxxxの変更をします • （しなもん）< それどうやってやるか知らないので、横 で⾒てていいですか？ • 作業を解説してもらいながら、質問しながら横で⾒る • 最終的にドキュメントにまとめて、次の作業時に横で ⾒てもらいながらやれるようにする
21. 少し慣れてきた期
22. 状態 • 1年後ぐらい • 障害対応に参加したり深夜メンテに参加するのが⾃然に なってきた
24. 問題の切り分けがスムーズになってくる • イレギュラーに沢⼭遭遇するうちに • 「これ、あの時に発⽣したやつだ！」 • 把握している範囲が増えて新種の切り分けも早くなる • インパクトの強い記憶は残りやすい • 解決できると成功体験が増える
25. 障害対応で得た知識を⽣かせるようになる • 「発⽣する問題の原因」がインプットされる • ⾃分の実装時に気をつけることが増えた • テストを厚めに書く部分やDBへの影響を⾒る etc • （これまで苦⼿だった）先輩のコードレビューでどこ を⾒ればいいのかが分かってくる
26. 難易度の⾼い障害に⽴ち向かう • 根本原因がわからないまま継続的に問題が起きることも ある • 詳しい⼈が周りにいない時とか特に • 苦しいが周辺知識の調査で理解が深まる
27. 仕切り期
28. 状態 • メンバーが増え、割と古株になってくる • 先輩が他のプロジェクトに配置されたりする • ⼤体の障害の発⾒・原因特定・修正をできる • チームメンバーにも対応してほしい
29. とりあえず発⽣したら叫ぶ • （しなもん）< うひょー • Slack or 物理 • アラートの通知をみたら、既読がわりに「おっ」 • ⾒てることを表明する • 問題が発⽣しているということがわかる
30. どこを⾒て何を考えたかを発信する • 新しくシステム触る⼈はベテランであっても、サービスド メインに近い情報は持ってない • xxのログを検索したんですけど • ooのグラフをみたら、xxが跳ねてて • ペア対応 • 横で切り分けてる様⼦を⾒てもらう
31. 分かってても⾔わない • 時間を多少かけても問題ない時は答えを⾔わない • ロールバックで⼀時的に収束した場合の問題特定など
32. ⼀⼈で対応しないための仕組み作り • 週替わり・⽇替わり等でon call担当を作る • SREっぽい組織化 • やらざるをえない状態を作るとやりやすい
33. まとめ • 障害対応は学びが多い • 戦⼒にならなくても良いのでまずは参加してみる • 発⽣した障害を学びにかえていく！ • 解決⼒が上がったら積み重ねを伝授していく • ⼀⼈で解決せず対応できる⼈を増やしてヘルシーな障害 対応ライフを
34. すぐに解決できない 障害が起きた時にやること
35. 例えば.. • リリース -> ロールバック -> 戻らない！ • アクセス急増で • 徐々に積み重ねで増えたチリツモのデータがある⽇いき なり起爆剤に…
36. ⼀⼈で解決・判断しようとしない • 対応できる仲間を呼ぶ • 「全体として被害が最⼩限になるには」を考えてから動 く
37. すぐ直せないと思ったらすぐに影響範囲に連絡する • （ユーザーさんに）お知らせ出す • 報告対象に連絡 • （対応者と報告対象をつなぐ）連絡担当を置く • 集中して調査しながら連絡のやり取りするの無理
38. できるだけ 障害対応を減らすには
39. コードレビュー • 条件分岐を意識する • if⽂の条件式逆めっちゃある • テストコードも逆さまの条件になってるとか割とある • 細かい書き⽅より条件があってるか • テストコードが間違ってるとテストがあってもバグる
40. コードレビュー • 副作⽤を意識 • 変更が意図しない他の部分に影響を与えるような実装 になってると危険 • ドメインロジックに詳しい⼈がレビューすると吉
41. コードレビュー • Active Recordで発⾏されるクエリを意識 • （データ規模によりますが） • ⼼配なところは発⾏クエリをみてexplainしたり • アクセスしてログ流して⾒て⾒たり
42. コードレビュー • redirect_to/renderのreturn忘れ • テストがないプロジェクトで後々⾒つかりがち • 1メソッド内で複数回呼ばれて500 • ⼀律でand returnをつけて安全側に倒すなど
43. コードレビュー • その変更、ロールバックできる？ • ⽚道切符の変更は危険 • 何かがあってロールバックした時に被害が拡⼤しない か
44. 安全に変更する仕組みを⼊れる • サーキッドブレーカーパターン • カナリアリリース
45. サーキッドブレーカーパターン • 「エラーレートがN%以上だったらこのエンドポイント へのアクセスをやめる」などを⾃動でするパターン • 「⼀定以上のエラーが起きる」などの条件で、ブレー カーを落としたり戻したりするようなイメージ • 何か起きた時に勝⼿に⾷い⽌めるような設定ができるの で便利
46. カナリアリリース • 新機能を⼀部のユーザーのみが使える状態にして段階的 にリリースしていく仕組み • 社内ユーザーのみ新機能の乗ったサーバにアクセスさ せるなどを⾏い、全ユーザーに影響が出ない形で新 バージョンの確認ができて便利
47. 障害対応レポート • 何か障害が発⽣したら書く習慣をつける • 発⾒・分析・対処の知⾒が蓄積される • 読み合わせ＆再発防⽌策は関係者以外もいるとよい • 「気をつける」は再発防⽌策にはならない • 気をつけなくていい仕組みを作っていく⽅に⼒を注ぐ
48. まとめ
49. システム障害との向き合い⽅ • 障害対応から学ぶことはたくさんある！ • （初⼼者）怖がらずに落ち着いて参加する • （経験者）積み重ねを伝授する動きを⾏う • 「全体として被害が最⼩限になるには」を意識 • ⽇々の仕組みづくりで不必要な障害対応を減らす！