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 Platform(Deno)を活用したインシデント対応標準化の取り組み
Search
beaverjr
August 04, 2024
0
33
Slack Platform(Deno)を活用したインシデント対応標準化の取り組み
Road to SRE NEXT@仙台での登壇資料です。
beaverjr
August 04, 2024
Tweet
Share
More Decks by beaverjr
See All by beaverjr
社内留学を通じて加速するプロダクトチームとのコラボレーション
beaverjr
1
1.3k
エンジニアリング組織論への招待.pdf
beaverjr
0
53
jaws-ug-tohoku-multi-account-tips
beaverjr
2
130
Molecule入門
beaverjr
0
31
Featured
See All Featured
Making Projects Easy
brettharned
115
5.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
GitHub's CSS Performance
jonrohan
1030
460k
4 Signs Your Business is Dying
shpigford
180
21k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
The Invisible Side of Design
smashingmag
297
50k
Git: the NoSQL Database
bkeepers
PRO
425
64k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Practical Orchestrator
shlominoach
186
10k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
13
1.9k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.8k
Transcript
Slack Platform(Deno)を活用した インシデント対応標準化の取り組み Road to SRE NEXT@仙台 @beaverjr
自己紹介 • Erika Takada / @beaverjr_50 • 株式会社モニクル SRE •
岩手県奥州市出身・在住 ◦ リモート勤務 • JAWS-UG いわて支部
アジェンダ • これまでのインシデント対応改善への取り組みと新たな課題 • 課題改善のためのインシデント対応標準化の方針 • Slack Automation Platformの紹介 •
インシデント対応標準化支援Botの概要 • Bot導入後の成果 • Next Action
これまでのインシデント対応改善への取り組みと新たな課題
これまでの取り組み 組織全体での基準やフローが明確で ない🔥 障害対応に慣れている人が全て対応 をし、負荷が高い🔥 インシデント対応後のふりかえりが行 われていない🔥 インシデント対応の共通認識、共通言 語ができた👌 ロールの分離ができた👌
対応後にはふりかえり会が行われるよ うになり、記録が残され対応プロセス やプロダクトの改善に繋げられるよう になった👌 2023.7- SREチーム立ち上げ後 ・SEV(Severity Level)、ロール(インシデントコマンダー /オペレーションリーダー)、対応フローを定義し、 インシデント管理表を整備 ・ポストモーテム Templateの整備、インシデント後のふりかえり会の開始 Before After
新たな課題 ふりかえり会で出てきたインシデント対応の課題 • フローに沿った対応の徹底が難しい ◦ 復旧作業を優先するあまり、役割の決定や関係者への連絡を忘れる ◦ 役割を定義したものの、実際の障害発生時にその通りに動けない • ふりかえり用のポストモーテム作成の負荷が高い
◦ ふりかえりに重点をおきたいのに、事実をまとめるのに時間が取られる
課題改善のためのインシデント対応標準化の方針
対応方針:初動対応の標準化 • War room(インシデント対応用Slackチャンネル)作成の改善 ◦ インシデント発生時にはできるだけシンプルに War roomを作成できるようにする ◦ プロダクトごとのインシデント管理表を元に役割や
War roomへ呼び出す人を定義しておき、インシ デント発生時には管理表を確認しなくても呼び出せるようにする • 情報共有 ◦ インシデント対応中の役割と責務がその場にいる人全員で認識できている状態にする ◦ 管理表とは別にWar room内で簡潔なインシデントフローを確認可能にする
対応方針:インシデント収束後の対応標準化 • 対応後のTodoを明確にする ◦ Todoリストの生成 ◦ 残タスクリマインダー • ふりかえり会の負荷軽減 ◦
ポストモーテムの起票及び作成のサポート ◦ ふりかえり会のスケジューリング
対応方針:実現方法 インシデントマネジメントとエンジニアリングのかけ算 - Speaker Deck • 勉強会で紹介されていたSlackBotに 感銘を受け、前述の課題解決にもつな がりそうだったので作成してみることに •
インシデントマネジメントSaaSも気に なったが、現時点でのインシデント発 生頻度等踏まえて今回はSlackBotで の改善に決定 https://waroom.com/
Slack Automation Platformの紹介
Slack Automation Platformとは より簡単でセキュアなアプリ開発体験を提供する新しいアプリ開発・実行基盤 • 2023.4 GA • https://api.slack.com/automation
従来のSlack App開発との違い Bolt(従来) Slack automation platform 対応言語 JavaScript (Node.js),Python,Java TypeScript(Deno)
ホスティング環境 任意のクラウドベンダー等で自前で用意 Slack が管理するホスティング環境 開発体験 構成設定などは基本的に GUIから行う Slack CLIでアプリのローカル実行、設定変更、 デプロイなど全ての操作を実行可能 GUIでの変更は不可 コスト ホスティング環境の維持コスト アプリの実行回数による課金 ワークスペースごと一定回数の無料分が含まれ ており、無料分を超過した場合にのみコストが 発生
Slack Automation Platformの要素 名称 説明 ワークフロー(Workflow) FunctionをStepとして組み合わせてやりたいことを実装する もの Triggerから入力を受け取る ファンクション(Function)
Workflowの中の一つ一つの処理。 Slack 内でのよくある操作を提供する 組み込みFunctionは、 Workflow定義の中で inputs を適切に設定するだけで利用 することができる トリガー(Trigger) 何かしらのタイミングでWorkflowを呼び出す データストア(Datastore) キーバリューストアのテーブルを n 個定義して、CLI のコマン ドやファンクションからデータを登録したり、クエリを実行する ことができる DynamoDBが使われている
Slack Automation Platformで開発してみて • 低コスト ◦ ホスティングを気にしなくていいので、 リソース自体のコストに加え運用コスト も低く抑えられる •
Slack CLIでの開発体験 ◦ Slackの管理画面を触らなくて済む ◦ CI/CDとの相性がいい • SREチームメンバーの知的好奇心を 満たす よかった点 苦労した点 • 要素を理解した上で実装するまで少 し苦労した • 他組織のメンバーとの連携がGUIで のワークフロー設定に比べて複雑 だった
インシデント対応標準化支援 Botの概要
Botの概要 • 前述の課題を解決するために開発した内製のSlack Bot • Irisという名前 • 初動対応の支援機能 ◦ War
Roomの作成 ◦ War Roomへの参加者自動招待 ◦ インシデント対応フローの案内 • 復旧後のフォローアップ機能 ◦ Todoの作成 ◦ タイムラインの出力
War Roomの作成 • SlackのショートカットでIrisを呼び出す と、情報収集用のフォームが表示され る • フォームでプロダクト、SEVを選択し、 ボタンをおすとWar Roomを作成する
War roomへの参加者自動招待 • フォームで選択したプロダクト、SEVに応じ て参加者がWar roomに自動招待される ◦ botが自動で呼び出しを行うことで、コミュニ ケーションコスト及び心理的負荷を軽減 •
Botを呼び出した元のチャンネルにもイ ンシデント情報を記載 ◦ 報告者や該当プロダクトの担当以外にも幅 広く情報を共有することが可能
インシデント対応手順の案内 • War room作成後に対応メンバー全員 で認識を揃えられるようにフローを案内 ◦ プロダクトごとのインシデント管理表の Link 提供 ◦
作成者からの状況共有 ◦ ロールを決定するフローを入れることでメン バーの認識を揃えて対応を進めやすくする
復旧後のフォローアップ • 復旧後のフォローアップ ◦ Todoリストを表示 • インシデントタイムラインを出力 ◦ メッセージに📌の絵文字でリアクションをし ておくと、出力ボタンでタイムラインを表示で
きる ◦ ポストモーテム作成の負荷削減
Bot導入後の成果
Bot導入後の成果 • リリースしたばかりのため、具体的な効果の測定には至っていない • 軽微なインシデントでも呼び出して使ってもらえている ◦ 問い合わせ →そのままスレッドで対応が進んでしまっていたものも、とりあえずインシデントチャン ネルが作られるように
Next Action
Next Action • Botを使った障害対応訓練の実施 ◦ インシデント対応に慣れることが最重要 • フィードバックの収集と機能拡充 ◦ Google
Forms等で実際にBotを使用するエンジニアからのフィードバックを積極的に収集 ◦ まずはどんどん使ってもらい、使用状況や改善点を見極める • Datastoreの活用 ◦ Datastoreの機能を活用し、Botの使用データやインシデント対応データを収集・分析 • 定期的な評価とふりかえり ◦ フェーズに応じて最適な取り組みをできるようにするため、取り組み自体のふりかえりを定期的に実 施
Thank you!