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

by sinamon129

Slide 1

Slide 1 text

システム障害との向き合い⽅ !TJOBNPO

Slide 2

Slide 2 text

⾃⼰紹介 RiLi, inc. 取締役 CTO RailsGirls Tokyo 5-11th coach 7th organizer ͠ͳ΋Μ @sinamon129

Slide 3

Slide 3 text

登壇内容を決めた経緯 • りさきゃん⽒からの要望 • 「個⼈的にはしなもんちゃんにごりごりテックな話をしてもらいたみ！！」 • いつもtechの中核を避けたような発表しかしてない • 特にOSS活動とかしてない（仕事が趣味みたいな） • これまでのエンジニア⼈⽣でインパクトがあったもの

Slide 4

Slide 4 text

前提⽂脈 • ⾃社プロダクト・C向け • 同じプロダクトを作るエンジニアは1 ~20⼈ぐらい • 仕様設計・開発・テスト・リリース・運⽤全て • いわゆるwebアプリケーション開発 • クラウドインフラ〜バックエンドまで

Slide 5

Slide 5 text

「システム障害対応」をやったことある⼈？✋

Slide 6

Slide 6 text

どんな種類のシステム障害があるか • 開発時の実装ミス（バグ） • ⼿動操作のミス • アクセスがドッカン • 使ってるサービスの不具合 • など、これらの単⼀もしくは複合

Slide 7

Slide 7 text

システム障害対応とは提供サービスが「期待しない状態」になっている時の対応

Slide 8

Slide 8 text

障害が起きてから収束するまで • （発⽣） • 発覚 • 調査 • ⼀次対応 • 収束 • ふりかえり（＆恒久対応）

Slide 9

Slide 9 text

エンジニア⼈⽣において障害対応で学んだことが多い

Slide 10

Slide 10 text

⾃分のフェーズ別障害対応

Slide 11

Slide 11 text

• あくまで私の経験。⼀例として。 • どういう⾵に障害対応と触れ合ってきたか • 「障害対応⾃分以外誰もできない」っていう相談に乗ることがなぜか多いのでその辺の話にも触れます

Slide 12

Slide 12 text

障害対応と深夜対応はすごい⼈がやるとおもってた期 • 社会⼈1年⽬ • (当時)10年物のサービスの部署に配属 • ウェブアプリケーションエンジニア20⼈ぐらい • なかなかに⼤きなコードベース • エラーがメールで⾶んでくるがどうしていいか分からない • ⾃分がバグを仕込んだと指摘された時以外何もできず

Slide 13

Slide 13 text

障害対応と深夜対応はすごい⼈がやるとおもってた期ベテランの⼈たちが対応してる、すごい興味はあるけど分からなさそう⾃分の仕事で精⼀杯深夜メンテナンスって何やるんだろう

Slide 14

Slide 14 text

初⼼者期

Slide 15

Slide 15 text

状態 • 社会⼈2年⽬（転職して前職に） • ウェブアプリケーションエンジニア6⼈ぐらい • 「1⼈でどうにかできる状態」に早くなるのが⽬標 • できないことを減らすために奮闘

Slide 16

Slide 16 text

障害発⽣させてしまうと焦るけど • （しなもん）＜やばいどうしよどうしよあばばば • （せんぱい）＜しなさん焦りすぎ・とりあえず落ち着いて。何をしたら何が起きたの？ • 先輩にしゃっと⾔われて冷静になるなどした • 焦るけど冷静になって対応した⽅が早く解決する • 落ち着いて⾒えるように⼼がけたら落ち着けるようになった

Slide 17

Slide 17 text

分からなくても参加する • （Slackにアラートがくる） • （しなもん）＜おっアラートだぞ • （先輩たち）＜これはxxxが原因かもですね • （しなもん）＜今何を⾒て⾔ってますか？ • 何か起きた時にどこを⾒ればいいか・どう問題を切り分ければいいかを学んだ

Slide 18

Slide 18 text

急がなくてもいい部分を担当する • ⼀次対応（とりあえずの復旧）が終わった後に障害報告を書いて、根本解決をしたりすることがよくある • 発⽣原因を踏まえて次に起こらないようにする仕組みづくりの部分をやらせてもらう • ⼀分⼀秒を争わないが、問題の近いところを理解できる

Slide 19

Slide 19 text

先輩より早く原因特定するゲームを実施する • 脳内実施 • まず発⽣に最初に気づけるようにする • ⼿がかりになりそうなことを話し合いながら解決の⽷⼝を集中して探す • ベテランの先輩より早く⾒つけられるとちょっと嬉しい • 何回もやってると段々切り分け⼒が上がる

Slide 20

Slide 20 text

やったことがないことに触れる • （せんぱい）< そろそろxxxxの変更をします • （しなもん）< それどうやってやるか知らないので、横で⾒てていいですか？ • 作業を解説してもらいながら、質問しながら横で⾒る • 最終的にドキュメントにまとめて、次の作業時に横で⾒てもらいながらやれるようにする

Slide 21

Slide 21 text

少し慣れてきた期

Slide 22

Slide 22 text

状態 • 1年後ぐらい • 障害対応に参加したり深夜メンテに参加するのが⾃然になってきた

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

問題の切り分けがスムーズになってくる • イレギュラーに沢⼭遭遇するうちに • 「これ、あの時に発⽣したやつだ！」 • 把握している範囲が増えて新種の切り分けも早くなる • インパクトの強い記憶は残りやすい • 解決できると成功体験が増える

Slide 25

Slide 25 text

障害対応で得た知識を⽣かせるようになる • 「発⽣する問題の原因」がインプットされる • ⾃分の実装時に気をつけることが増えた • テストを厚めに書く部分やDBへの影響を⾒る etc • （これまで苦⼿だった）先輩のコードレビューでどこを⾒ればいいのかが分かってくる

Slide 26

Slide 26 text

難易度の⾼い障害に⽴ち向かう • 根本原因がわからないまま継続的に問題が起きることもある • 詳しい⼈が周りにいない時とか特に • 苦しいが周辺知識の調査で理解が深まる

Slide 27

Slide 27 text

仕切り期

Slide 28

Slide 28 text

状態 • メンバーが増え、割と古株になってくる • 先輩が他のプロジェクトに配置されたりする • ⼤体の障害の発⾒・原因特定・修正をできる • チームメンバーにも対応してほしい

Slide 29

Slide 29 text

とりあえず発⽣したら叫ぶ • （しなもん）< うひょー • Slack or 物理 • アラートの通知をみたら、既読がわりに「おっ」 • ⾒てることを表明する • 問題が発⽣しているということがわかる

Slide 30

Slide 30 text

どこを⾒て何を考えたかを発信する • 新しくシステム触る⼈はベテランであっても、サービスドメインに近い情報は持ってない • xxのログを検索したんですけど • ooのグラフをみたら、xxが跳ねてて • ペア対応 • 横で切り分けてる様⼦を⾒てもらう

Slide 31

Slide 31 text

分かってても⾔わない • 時間を多少かけても問題ない時は答えを⾔わない • ロールバックで⼀時的に収束した場合の問題特定など

Slide 32

Slide 32 text

⼀⼈で対応しないための仕組み作り • 週替わり・⽇替わり等でon call担当を作る • SREっぽい組織化 • やらざるをえない状態を作るとやりやすい

Slide 33

Slide 33 text

まとめ • 障害対応は学びが多い • 戦⼒にならなくても良いのでまずは参加してみる • 発⽣した障害を学びにかえていく！ • 解決⼒が上がったら積み重ねを伝授していく • ⼀⼈で解決せず対応できる⼈を増やしてヘルシーな障害対応ライフを

Slide 34

Slide 34 text

すぐに解決できない障害が起きた時にやること

Slide 35

Slide 35 text

例えば.. • リリース -> ロールバック -> 戻らない！ • アクセス急増で • 徐々に積み重ねで増えたチリツモのデータがある⽇いきなり起爆剤に…

Slide 36

Slide 36 text

⼀⼈で解決・判断しようとしない • 対応できる仲間を呼ぶ • 「全体として被害が最⼩限になるには」を考えてから動く

Slide 37

Slide 37 text

すぐ直せないと思ったらすぐに影響範囲に連絡する • （ユーザーさんに）お知らせ出す • 報告対象に連絡 • （対応者と報告対象をつなぐ）連絡担当を置く • 集中して調査しながら連絡のやり取りするの無理

Slide 38

Slide 38 text

できるだけ障害対応を減らすには

Slide 39

Slide 39 text

コードレビュー • 条件分岐を意識する • if⽂の条件式逆めっちゃある • テストコードも逆さまの条件になってるとか割とある • 細かい書き⽅より条件があってるか • テストコードが間違ってるとテストがあってもバグる

Slide 40

Slide 40 text

コードレビュー • 副作⽤を意識 • 変更が意図しない他の部分に影響を与えるような実装になってると危険 • ドメインロジックに詳しい⼈がレビューすると吉

Slide 41

Slide 41 text

コードレビュー • Active Recordで発⾏されるクエリを意識 • （データ規模によりますが） • ⼼配なところは発⾏クエリをみてexplainしたり • アクセスしてログ流して⾒て⾒たり

Slide 42

Slide 42 text

コードレビュー • redirect_to/renderのreturn忘れ • テストがないプロジェクトで後々⾒つかりがち • 1メソッド内で複数回呼ばれて500 • ⼀律でand returnをつけて安全側に倒すなど

Slide 43

Slide 43 text

コードレビュー • その変更、ロールバックできる？ • ⽚道切符の変更は危険 • 何かがあってロールバックした時に被害が拡⼤しないか

Slide 44

Slide 44 text

安全に変更する仕組みを⼊れる • サーキッドブレーカーパターン • カナリアリリース

Slide 45

Slide 45 text

サーキッドブレーカーパターン • 「エラーレートがN%以上だったらこのエンドポイントへのアクセスをやめる」などを⾃動でするパターン • 「⼀定以上のエラーが起きる」などの条件で、ブレーカーを落としたり戻したりするようなイメージ • 何か起きた時に勝⼿に⾷い⽌めるような設定ができるので便利

Slide 46

Slide 46 text

カナリアリリース • 新機能を⼀部のユーザーのみが使える状態にして段階的にリリースしていく仕組み • 社内ユーザーのみ新機能の乗ったサーバにアクセスさせるなどを⾏い、全ユーザーに影響が出ない形で新バージョンの確認ができて便利

Slide 47

Slide 47 text

障害対応レポート • 何か障害が発⽣したら書く習慣をつける • 発⾒・分析・対処の知⾒が蓄積される • 読み合わせ＆再発防⽌策は関係者以外もいるとよい • 「気をつける」は再発防⽌策にはならない • 気をつけなくていい仕組みを作っていく⽅に⼒を注ぐ

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

システム障害との向き合い⽅ • 障害対応から学ぶことはたくさんある！ • （初⼼者）怖がらずに落ち着いて参加する • （経験者）積み重ねを伝授する動きを⾏う • 「全体として被害が最⼩限になるには」を意識 • ⽇々の仕組みづくりで不必要な障害対応を減らす！