Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
インシデント発生時のSlack / we-fight-with-slack
hideki kinjyo
PRO
July 08, 2019
Technology
1
2.1k
インシデント発生時の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
#phperkaigi 作って遊ぼう!Composer Plugin
o0h
PRO
1
620
#phperkaigi GitHub Actions使っていますか?では、cs2prも一緒にいかがですか?
o0h
PRO
0
1k
オブジェクト指向のこころ: 第25章 / DESIGN PATTERNS EXPLAINED: chapter-25
o0h
PRO
0
39
オブジェクト指向のこころ: 第22章 / DESIGN PATTERNS EXPLAINED: chapter-22
o0h
PRO
0
45
オブジェクト指向のこころ: 第19章 / DESIGN PATTERNS EXPLAINED: chapter-19
o0h
PRO
0
2
オブジェクト指向のこころ: 第11章 / DESIGN PATTERNS EXPLAINED: chapter-11
o0h
PRO
0
19
#phpcon2021 ステップ実行だけじゃないXdebug / hello-xdebug
o0h
PRO
4
970
オブジェクト指向のこころ: 第8章 / DESIGN PATTERNS EXPLAINED: chapter-8
o0h
PRO
0
20
データベース・リファクタリングを読む / hello-database-refactoring
o0h
PRO
0
29
Other Decks in Technology
See All in Technology
〇〇みたいな検索作ってと言われたときに考えること / thinking before developing search system like that one
ryook
5
2.7k
ソフトウェアアーキテクチャの基礎: Software Architecture in a Nutshell
snoozer05
30
8.8k
Trusted Web プロトタイプ
finengine
0
330
eBPFで実現するコンテナランタイムセキュリティ / Container Runtime Security with eBPF
tobachi
PRO
5
1.7k
LINSTOR — это как Kubernetes, но для блочных устройств
flant
0
3.1k
漫画で使えそうな背景画像をblenderを使って作ってみた!
nokonoko1203
1
280
Istioを活用したセキュアなマイクロサービスの実現/Secure Microservices with Istio
ido_kara_deru
3
420
eBPF-based Container Networking
johnlin
2
1.1k
DeFiChain Tech Talk - DFI Uniswap Staking, DeFi Options & DeFi Meta Chain
uzyn
0
110
ここが好きだよAWS管理ポリシー_devio2022/i_am_iam_lover
yukihirochiba
0
3.2k
EKS AnywhereとIAM Anywhereを組み合わせてみた
regmarmcem
0
360
脆弱性スキャナのOWASP ZAPを コードベースで扱ってみる / OWASP ZAP on a code base
task4233
1
230
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
29
4.4k
Facilitating Awesome Meetings
lara
29
4.1k
Web development in the modern age
philhawksworth
197
9.3k
Intergalactic Javascript Robots from Outer Space
tanoku
260
25k
Making Projects Easy
brettharned
98
4.4k
Rebuilding a faster, lazier Slack
samanthasiow
62
7.3k
Mobile First: as difficult as doing things right
swwweet
213
7.6k
Pencils Down: Stop Designing & Start Developing
hursman
113
9.8k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
316
19k
Imperfection Machines: The Place of Print at Facebook
scottboms
253
12k
Support Driven Design
roundedbygravity
87
8.6k
The World Runs on Bad Software
bkeepers
PRO
57
5.4k
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. 事例を蓄積していく
細かく決めすぎない! • 「決めごと」は萎縮を招く • ⽬的意識だけ共有して、柔軟性を尊重 • 「(誰でも)気持ちよく動くには?」の プラクティスをまとめていくのが⼤事 • いつも対応してる⼈の”アルアル”観点
͓͖߹͍͍͖ͨͩ ͋Γ͕ͱ͏͍͟͝·ͨ͠ʂ