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
インシデント発生時のSlack / we-fight-with-slack
Search
hideki kinjyo
PRO
July 08, 2019
Technology
1
3k
インシデント発生時のSlack / we-fight-with-slack
Tech-on MeetUp#07「OpsとDevの蜜月な関係」
https://techplay.jp/event/734673
「インシデント対応でSlackどう使おうか」という話をしました
hideki kinjyo
PRO
July 08, 2019
Tweet
Share
More Decks by hideki kinjyo
See All by hideki kinjyo
組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する #phpconfuk
o0h
PRO
6
2.3k
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
540
Composerの依存解決 #phpstudy
o0h
PRO
0
130
「影響が少ない」を自分の目でみてみる
o0h
PRO
3
1.8k
PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- #phperkaigi
o0h
PRO
0
1.7k
もう少しテストを書きたいんじゃ〜 #phpstudy
o0h
PRO
23
5.3k
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
9
4.1k
色んなオートローダーを覗き見る #phpcon_okinawa
o0h
PRO
5
750
ヒューマンエラーの本を読んだ ~報告会~
o0h
PRO
3
380
Other Decks in Technology
See All in Technology
ソースコードを読むときの思考プロセスの例 ~markdownのレンダリング方法を知りたかった2 markdownパッケージ~
sat
PRO
0
110
ubuntu-latest から ubuntu-slim へ移行しよう!コスト削減うれしい~!
asumikam
0
320
AI時代におけるドメイン駆動設計 入門 / Introduction to Domain-Driven Design in the AI Era
fendo181
0
410
品質保証の取り組みを広げる仕組みづくり〜スキルの移譲と自律を支える実践知〜
tarappo
1
230
re:Inventに行きたい いつか行きたい 行けるようにできることは?
yama3133
0
110
ソフトウェア品質を支える テストとレビュー再考 / 吉澤 智美さん
findy_eventslides
1
520
2025 DHI Lightning Talks
digitalfellow
0
110
Logik: A Free and Open-source FPGA Toolchain
omasanori
0
220
LLM APIを2年間本番運用して苦労した話
ivry_presentationmaterials
11
9.6k
こんな時代だからこそ! 想定しておきたいアクセスキー漏洩後のムーブ
takuyay0ne
3
320
仕様駆動開発を実現する上流工程におけるAIエージェント活用
sergicalsix
12
6k
MCP サーバーの基礎から実践レベルの知識まで
azukiazusa1
24
11k
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
660
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.5k
GraphQLとの向き合い方2022年版
quramy
49
14k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Six Lessons from altMBA
skipperchong
29
4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
How GitHub (no longer) Works
holman
315
140k
Designing for humans not robots
tammielis
254
26k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
640
Transcript
Slackによる インシデント対応 Tech-on MeetUp#07 Hideki Kinjyo twitter: @o0h_ / github:
o0h
ࣗݾհ • ίωώτגࣜձࣾ • αʔόʔαΠυΤϯδχΞ • ओʹCakePHPͳͲ
最近は監視をhogehogeしています 会社のブログ -> http://tech.connehito.com/archive/author/o0h
今⽇のお話: インシデント発⽣時の コミュニケーションを整える with Slack
(⽐較的⼩さなチームで) インシデント時の緊急対応、 どうしていますか?
我々のチームの規模感 αʔόʔαΠυ Σϒϑϩϯτ ϞόΠϧ Πϯϑϥ
我々のチームの規模感 αʔόʔαΠυ Σϒϑϩϯτ ϞόΠϧ Πϯϑϥ • めっちゃくちゃ少ない、って程でもないが • DevもOpsも⼊り混じってるよ〜くらいのサイズ
⼩さいチームの良い所/悪い所 • 良い所: • 知識量が分散しにくい • コミュニケーションがとりやすい • 悪い所: •
「仕組み化」が過剰コストになりがち
この状態で 「インシデント対応」 どうしていくか?
そもそもの話として・・・ • インシデントが発⽣したときって • いろんな判断⼒が求められたり • やったこと無いとムズい(怖い)し • テンパるし
怖くて孤独
チームの「良さ」を活かして 問題の「難しさ」に 対処したい!
⼩っちゃいからさ! • まだまだ整備(やマンパワー)が 追いついていない部分も多いが • 全員が互いの顔や職務を知っているくらいの 距離感にいるから • 「誰に任せる」「⾃分がやる」の綱引きを スムーズにやりやすいよう整えれば勝てる!
武器:コミュニケーション
Slackでザクザク対応していく
いざという時のための 「Slackどう使う?」の ふわっとガイドライン
コネヒトでの流れ 1. 障害検知 => アラートに気づいた誰かが投げる 2. Slack上にテンポラリな「対応専⽤チャンネル」作成 => インシデントごとの使い捨て 3.
調査 => その時に⼿を動かせる⼈がいっぱい頑張る 4. ⼀次対応 => その場でできることをいっぱい頑張る 5. ポストモーテム
コネヒトでの流れ 1. 障害検知 => アラートに気づいた誰かが投げる 2. Slack上にテンポラリな「対応専⽤チャンネル」作成 => インシデントごとの使い捨て 3.
調査 => その時に⼿を動かせる⼈がいっぱい頑張る 4. ⼀次対応 => その場でできることをいっぱい頑張る 5. ポストモーテム
実際の例
なんでチャンネルを? • 「対応チーム」がないので 「騒ぎ⽴てるのをわかりやすくしたい」。 関係者全員の温度感を上げるのも必要 • (⼀次対応の完了後に) 恒久対応時に速やかに情報を整理したい &振り返り・検証材料 •
全てが完了したらチャンネルごとアーカイブ
チャンネルをどう使うか? • 開設後に即座に • エンジニア、ディレクターをinvite • 検知したエビデンス、いま分かっているこ とを貼り付ける • 対応可能な⼈の確認(リアクションを⾶ばす)
チャンネルをどう使うか? • 状況の進展に応じて • 役割分担(cf: ⼊⾨監視「インシデント管理」 (P48)) • 調査状況や判明した事実、仮説を随時投げ 込む
チャンネルをどう使うか? • ⼀次対応が完了したら • 「収束した」と判断した材料を共有、合意を取る • ポストモーテムに向けて • 根本原因の調査や報告の取りまとめを誰が&どう進める か?の確認
• すべての振り返りを完了させたらチャンネルのクローズ
作業フローの整備にあたって • 「インシデント対応⼼構え」の⾔語化、共有 • ユーザー被害の沈静化 >> 根本原因究明 • 事実と推測を切り分ける •
最悪の事態を想定する etc • 「実際の流れ」のシミュレーション、 メンバー全員による共有会の実施
まとめ!
おさらい 1. インシデント対応時に「重要なこと」「優先 順位」の明確化、認識の共通化をする 2. それらの⽬的に即した「情報流通のあり⽅」 のイメージを持つ 3. 事例を蓄積していく
細かく決めすぎない! • 「決めごと」は萎縮を招く • ⽬的意識だけ共有して、柔軟性を尊重 • 「(誰でも)気持ちよく動くには?」の プラクティスをまとめていくのが⼤事 • いつも対応してる⼈の”アルアル”観点
͓͖߹͍͍͖ͨͩ ͋Γ͕ͱ͏͍͟͝·ͨ͠ʂ