ameba-incident-management

Transcript

1. おーい磯野〜！ IncidentManagementしようぜ〜！ 歴史あるAmebaのシステムでIncidentManagementを導入した話
2. Agenda 02 04 History & Problem Amebaの歴史について Use case for datadog Datadog Incidentを用いた活用例 01 03 05 Introduction Incident Managementを行う上で 決定すべき重要な要素について説明 自己紹介 SRG紹介 Amebaについて Closing まとめ お知らせ What’s incident management
3. Introduction 01 自己紹介・SRG/Amebaについて
4. 田中 秀樹 Engineer / PjM / SRG Engineering Manager 最近数年ぶりにKubectlを実行したSREの皮を被ったPjM中心の人間 IncidentManagementやFinOpsを推進するための文化形成だったりが最近のマ イブーム Amebaへembedded SREとして参画 今年面白かった漫画ベスト 3は 「図書館の大魔術師」 「呪術廻戦」 「完璧すぎて可愛げがないと婚約破棄された聖女は隣国に売られる」
5. What’s SRG 〜2015年 メディア事業全体のインフラ組織 オンプレミス環境を中心とした昔ながら のインフラエンジニア 2015年〜2022年 メディア事業横断のSRE組織へ クラウドを中心とした サービスインフラエンジニアへ 社内向けSRE as a Serviceを提供 Service Reliability Group の略称であり、会社を横断する SRE組織 2022年 〜 「サイバーエージェントグループの信頼 性を “横断的に” 向上させる」というミッ ションを掲げた 横断SRE組織へ
6. What’s Ameba Amebaはブログを中心としたメディアプラットフォーム
7. History & Problem Amebaの歴史と抱える問題について 02
8. Ameba History Amebaはブログを中心としたメディアプラットフォーム
9. Ameba History 来年2024年で20周年を迎える歴史の長いサービス
10. Ameba History 成長期・成熟期を経て 再生期へ
11. Ameba History 成長期・成熟期を経て 再生期へ 今日メインでお話しする内容はココ
12. Ameba Problem 各フェーズにおける人とシステムの変化に伴って 起きた問題を話すよ！
13. Ameba Problem 導入期〜成長期 における人とシステムの関連性
14. Ameba Problem 導入期〜成長期 における人とシステムの関連性 成長期初期段階ではシステム規模は小さく、開発者も少ない状況です。 ここから双方とも加速度的に増大していきます 開発者が担当するシステム
15. Ameba Problem 成熟期 における人とシステムの関連性
16. Team A Team B Team C Team D システムの拡大・人員増加に伴ってそれぞれのグルーピングも促 進され、チームでカバレッジを上げていく体制へ Ameba Problem 機能A 機能B 機能C データD 成熟期 における人とシステムの関連性
17. Ameba Problem 再生期 における人とシステムの関連性
18. Team A Team B Team C Team D 再生期に入ると人員への投資は減少し、 システムも不要な物がクローズされていくフェーズへ Ameba Problem 機能A 機能B 機能C データD 再生期 における人とシステムの関連性
19. Team A Team B Team C Team D システム間依存などの問題から、 コストパフォーマンスが悪いシステムが削除される訳ではなく、 徐々にカバレッジの低下が散見される状態へ Ameba Problem 機能A 機能B 機能C データD 再生期 における人とシステムの関連性
20. Team A Team B Team C Team D 「システム数 >>> 開発者数」が促進していき、 影響度は大きくないが、担当する人もいない システムが増加していく Ameba Problem 機能A 機能B 機能C データD 再生期 における人とシステムの関連性
21. 再生期にて発生した問題 Team A Team B Team C Team D 担当者不在のため、アラートが鳴っても放置され続けるシステム群 Ameba Problem 機能A 機能B 機能C データD
22. 再生期にて発生した問題 Team A Team B Team C Team D 実質的に特定の人間（いいやつ）に依存したシステム保守体制 Ameba Problem 機能A 機能B 機能C データD
23. 再生期にて発生した問題 Team A Team B Team C Team D でもなかなか評価されないインシデント解決マン・・・！ ※定量評価・目標設定がしやすい新規開発などが評価しやすい Ameba Problem Best engineer 新規開発 機能A 機能B 機能C データD
24. 再生期にて発生した問題 Team A Team B Team C Team D 担当外のシステムであるがために、 インシデントの解決に想定以上の時間を要してしまう Ameba Problem 機能A 機能B 機能C データD
25. 再生期にて発生した問題 Team A Team B Team C Team D 過去の対応履歴が適切に情報集約されておらず、 毎回インシデント解決に要する時間が想定以上に必要となる Ameba Problem ?? 機能A 機能B 機能C データD
26. 再生期にて発生した問題 Team A Team B Team C Team D それら複合的な要因により恒久対応も行われず、 同じアラートが何度も再発している Ameba Problem 機能A 機能B 機能C データD
27. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
28. Problem Summary Incident Managementせな やばいやろこれ・・！ 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
29. What’s incident management IncidentManagementを行う上で重要な要素 03
30. ってかインシデントマネジメントって・・・ どうやってやるんだ・・・？
31. What’s Incident management Incident Managementは障害などにより正常な状態でなくなったシステムやサービスを 迅速に元の状態へ戻すプロセス・アクティビティの事を指します 発生したインシデントの影響を最小限に収めるだけでなく、 ユーザーや関連各所へのコミュニケーションの円滑化や復旧プロセスの継続的改善を 目的とした動きを行う必要があります
32. Incident Management/Three Keys インシデントの優先順位 重要度・影響度などによって決定される Severity Levelと呼ばれる4-5段階の指標に よって優先順位が決定される Triage インシデントが発生した際にどのようにして 解決まで導くかを定義したもの Incident response flow Structure インシデントを解決するための体制 主にインシデント解決に責任を持つIncident Commander(IC)がキーパーソン となる インシデントマネジメント成功させる重要な3要素 成功 = インシデントを迅速に復旧させる
33. インシデントの優先順位 重要度・影響度などによって決定される Severity Levelと呼ばれる4-5段階の指標に よって優先順位が決定される Triage インシデントが発生した際にどのようにして 解決まで導くかを定義したもの Incident response flow Structure Incident Management/Three Keys インシデントを解決するための体制 主にインシデント解決に責任を持つIncident Commander(IC)がキーパーソン となる インシデントマネジメント成功させる重要な3要素
34. トリアージとはインシデントの 優先順位を決定する事です 限られた人的リソースの中、 複数インシデントが発生した際にどれを急いで復旧するのかの決定する点にあります 優先順位を決定するために、事前に条件設定をする必要があります Triage engineer System A Alert System B Alert システムAとBどちらを優先して 復旧すべき・・・？
35. Amebaのトリアージを紹介 Triage
36. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない ※Amebaでの導入事例 ベースでお話しします
37. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない Severity(SEV) (優先度の数値化) 高 低
38. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない SEV Level毎のざっくりとした影響度
39. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない マジでやばい 役員報告レベル
40. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない かなりやばい 事業責任者レベル マジでやばい 役員報告レベル
41. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない かなりやばい 事業責任者レベル マジでやばい 役員報告レベル ユーザ影響でてるので ユーザアナウンス必要
42. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない かなりやばい 事業責任者レベル マジでやばい 役員報告レベル ユーザ影響でてるので ユーザアナウンス必要 軽微な障害 現場だけで復旧可能
43. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない かなりやばい 事業責任者レベル マジでやばい 役員報告レベル ユーザ影響でてるので ユーザアナウンス必要 軽微な障害 現場だけで復旧可能 SEV判断を行うために明確なある程度明確な定義が必要
44. Triage メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで対応・方針策定が必要なレベル SEV1 SEV2 SEV3 SEV4 Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの対応方針の決定が必要 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、インシデントコマンダーは介入しない かなりやばい 事業責任者レベル マジでやばい 役員報告レベル ユーザ影響でてるので ユーザアナウンス必要 軽微な障害 現場だけで復旧可能 SEV Levelによって対応フローも登場人物も大きく異なる
45. インシデントの優先順位 重要度・影響度などによって決定される Severity Levelと呼ばれる4-5段階の指標に よって優先順位が決定される Triage インシデントが発生した際にどのようにして 解決まで導くかを定義したもの Incident response flow Structure Incident Management/Three Keys インシデントを解決するための体制 主にインシデント解決に責任を持つIncident Commander(IC)がキーパーソン となる インシデントマネジメント成功させる重要な3要素
46. Structure インシデントを迅速に解決するに当たって、 Incident Commander(以降 : IC)の立て付けが非常に重要になります IC
47. Structure 例えば複数のエスカレーションやエンドユーザへのアナウンスが必要となる 影響度の高い障害においては ICがコミュニケーション周りを請け負うことで、 開発者はシステムの復旧作業に集中可能となります IC engineer engineer System B System A Lead Alert Alert escalation announce End user
48. ICがいないケースと比べて Engineerの負担が軽い事が分かります engineer System A Alert Lead System B Alert End user ??? ??? Structure
49. Structure まずはICを立て付けてください。 このポジションはエンジニアに限らず、 PMにも担当してもらうケースがあるため、職種を超えた調整が必要になります IC engineer engineer System B System A Lead Alert Alert escalation announce End user
50. インシデントの優先順位 重要度・影響度などによって決定される Severity Levelと呼ばれる4-5段階の指標に よって優先順位が決定される Triage インシデントが発生した際にどのようにして 解決まで導くかを定義したもの Incident response flow Structure Incident Management/Three Keys インシデントを解決するための体制 主にインシデント解決に責任を持つIncident Commander(IC)がキーパーソン となる インシデントマネジメント成功させる重要な3要素
51. Incident response flow トリアージ・ICを立て付けた後は SEV毎の対応フローを整備しましょう トリアージもICも単独では機能しません 必ず対応フローとセットで展開しましょう engineer engineer System B System A Alert Alert IC Lead escalation announce End user
52. Incident response flow Case SEV4 engineer engineer System B System A Alert Alert 復旧対応が必要な全てのインシデント（アラート） 現場エンジニアのみで復旧可能であり、 インシデントコマンダーは介入しない 現場エンジニアのみで復旧対応まで完遂 resolve resolve
53. Incident response flow engineer engineer System B System A Alert Alert ICが必須であり、復旧に関する 意思決定・関連各所へのコミュニケーションを実施 resolve resolve IC announce End user escalation escalation 対ユーザへのアナウンス・コミュニケーションが必要なインシデント 現場エンジニアだけでは完結せず、関連サービスや対外的な コミュニケーションが必要なインシデント PMやエンジニアリーダーレベルでの対応方針のハンドリングや意思決定が必要 Case SEV3
54. Incident response flow engineer engineer System B System A Alert Alert resolve resolve IC announce End user escalation escalation Lead escalation Ameba事業の継続可能性に関わるインシデント 事業運営にクリティカルな影響があり事業責任者レベルでの 対応方針の決定が必要 ICが必須であり、 事業責任者のエスカレーション・意思決定の調整を含めた対応が必要 Case SEV2
55. Incident response flow engineer engineer System B System A Alert Alert resolve resolve IC announce End user escalation escalation Lead escalation CTO escalation ICが必須であり、事業責任者や CTOを含めたエスカレーションが必要となり、 全社横断での意思決定の調整を含めた対応が必要 メディア事業の継続可能性に関わるインシデント Ameba単体でなく、事業部ひいては全社レベルで 対応・方針策定が必要なレベル Case SEV1
56. Incident Management/Three Keys インシデントの優先順位 重要度・影響度などによって決定される Severity Levelと呼ばれる4-5段階の指標に よって優先順位が決定される Triage インシデントが発生した際にどのようにして 解決まで導くかを定義したもの Incident response flow Structure インシデントを解決するための体制 主にインシデント解決に責任を持つIncident Commander(IC)がキーパーソン となる インシデントマネジメント成功させる重要な3要素 これら３点を定義することが最初のステップ
57. Use case for datadog 04 Datadog Incidentを用いた活用例
58. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
59. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない 3 keysにて解決できるのは インシデントを迅速に収束することのみ
60. これからIncidentManagementしていくけど、 大前提としていい感じに運用できて、 かつ各種問題の解決ができるようなツールが必要だな？
61. Use case for datadog 各種問題を解決するため、 AmebaではDatadog Incidentを採用する方針にしました 1. Datadog自体が監視ツールであるため、インシデントとの親和性が高い 2. Slackなどのコミュニケーションツールとの連携性が高い 3. Postmortem作成・連携といったインシデント関連の機能が充実している 4. インシデント対応に関する各種数値が取得可能
62. Use case for datadog とりあえず使用感を見てみよう！ 各種問題を解決するため、 AmebaではDatadog Incidentを採用する方針にしました 1. Datadog自体が監視ツールであるため、インシデントとの親和性が高い 2. Slackなどのコミュニケーションツールとの連携性が高い 3. Postmortem作成・連携といったインシデント関連の機能が充実している 4. インシデント対応に関する各種数値が取得可能
63. Datadogを開いて左ツリーの「Service Mgmt」配下の 「Incidents」がIncidentManagementに関する機能となります Use case for datadog
64. Incident一覧の画面になります (細かい情報は黒で塗りつぶしてます) Use case for datadog
65. インシデントタイトル Use case for datadog これはテストインシデントです 障害 太郎 やりとりしているslackチャンネル SEV Level インシデントステータス Datadog Incidentにて利用できる カスタムパラメータ A team monitor aws-hoge hoge-api
66. チケット化されたインシデントのStatus別件数 Use case for datadog
67. トリアージ別インシデント件数 Use case for datadog
68. Postmortem(振り返り)実施済みかどうか Use case for datadog
69. 新規でインシデントチケットを切りたい場合はココ Use case for datadog
70. Use case for datadog 以下の各種項目を入力してインシデントチケットを作成 1. インシデントタイトル 2. Severity Level 3. Incident Commander 4. Attributes (カスタム可能) 5. Notification
71. Use case for datadog 例えばこんな感じで作成すると・・
72. Use case for datadog Datadog側のインシデント画面
73. Use case for datadog Sev Level / Status Slack link 何が起こったのか？ ユーザ影響はあるのか？ なぜ起こったのか？ を記載します。
74. Use case for datadog Datadog tagとAttributeを連携させる事が可能 例えばAPI・機能毎のインシデント件数を 取得する事が可能になる hoge-api hoge aws-hoge blog
75. Use case for datadog インシデント対応における Timelineを記載するページ どう調査を進めたか？ 調査の結果、どういった情報があったか等
76. Use case for datadog Slackで障害に関するやりとりしていたら二重 管理になるんじゃ・・・？
77. Use case for datadog Teamに紐付けたメンバーが Slackチャンネルに自動追加される（上記） 事前に設定した命名規則を元にDatadog君が Slackでインシデント用のチャンネルを作成
78. Use case for datadog ご安心を！ Slackの投稿に📌の絵文字をつけると Datadog君がDatadog Incidentの Timelineに転記してくれます
79. Use case for datadog ご安心を！ Slackの投稿に📌の絵文字をつけると Datadog君がDatadog Incidentの Timelineに転記してくれます
80. 使い勝手良さそう・・・！ めっちゃ便利やないか　
81. でもAmebaの課題解決はできるの？
82. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
83. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
84. Problem 　アラートが鳴っても放置されており、再発もしている engineer System B System A Crit Alert Crit Alert Incident A Incident B engineer 意外と解決案は簡単で、全ての Critical Alertに対して Incidentチケットを作成して私が担当を割り当てる形にしました ※Re-triggered-Alertは追記 ※前提としてシステムとTeamを紐付ける必要があり
85. Problem Incident Statusの定義において “Completed” を追加 振り返り及び恒久対応を以って、当該 Statusとする方針に 　アラートが鳴っても放置されており、再発もしている
86. Problem 1. 再発防止のためのシステム的な恒久対応 2. システム上問題ない場合は監視の閾値見直し Amebaでは上記対応をインシデントオーナーが 責任持って進める事で、 Crit Alertの再発数の抑制に成功 　アラートが鳴っても放置されており、再発もしている
87. Problem Incidentの “Remediation” タブにて残対応が管理できるため、 ここで「誰が」「いつまでに」「何をやるか」を管理し、 オーナーが責任を持って Completedになるまで対応を進めます 　アラートが鳴っても放置されており、再発もしている
88. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
89. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
90. Problem 特定の開発者にIncident解決対応が集約されている Incident解決に貢献してもなかなか評価されない engineer System B System A Crit Alert Crit Alert Incident A Incident B engineer
91. Problem 特定の開発者にIncident解決対応が集約されている 障害 太郎 障害 二郎 障害 三郎 障害 四郎 障害 堀太郎 hoge男 moge子 現場猫 範馬刃牙 愚地独歩 Datadog Incidentでは Incident CommanderやResponder(反応してくれた人) を集計できるメトリクスが用意されています Amebaでは当該メトリクスを参考に特定の メンバーに対応が集約しないよう運用しています ※自動化検討中
92. Problem 特定の開発者にIncident解決対応が集約されている 障害 太郎 障害 二郎 障害 三郎 障害 四郎 障害 堀太郎 hoge男 moge子 現場猫 範馬刃牙 愚地独歩 "queries": [ { "data_source": "incident_analytics", "name": "query1", "search": { "query": "" }, "indexes": [ "*" ], "compute": { "aggregation": "count" }, "group_by": [ { "facet": "commander.name", "limit": 10, "sort": { "aggregation": "count", "order": "desc" } } ] } ]
93. Problem Incident解決に貢献してもなかなか評価されない 取得した対応件数を元に毎月 Slackで上位入賞者を発表
94. Problem Incident解決に貢献してもなかなか評価されない 取得した対応件数を元に毎月 Slackで上位入賞者を発表 組織に対して明確に認知させることが重要
95. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
96. Problem Summary 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
97. Problem 過去のインシデント対応の履歴が集約化されていない 1. Datadog Incidentでインシデントチケット集約化 2. Datadog Tagsで付与したタグを元に、インシデントの検 索性能を向上
98. Problem Summary 100点ではないが、 これらの運用でAmebaが抱えている問題が解決できつつある状況 1. 　アラートが鳴っても放置されており、再発もしている 2. 　特定の開発者にIncident解決対応が集約されている 3. 　Incident解決に貢献してもなかなか評価されない 4. 　インシデント解決に想定以上の時間を要してしまう 5. 　過去のインシデント対応の履歴が集約化されていない
99. Closing 05 まとめ & お知らせ
100. 事業の状態推移によって システム規模に対する開発者数が低下 し、 インシデントに関する諸問題が浮き彫りとなる事態はどの事業にも起こりうる インシデントマネジメントを推進するためには以下の３要素が重要 1. トリアージの策定 2. インシデントコマンダーの選出 3. インシデント対応フローの策定 Datadog Incidentはとてもすごく便利だし、解決できる問題も多い ※Beta版の便利機能とかも気づけば増えてるのでこれからもっとよくなる予感 まとめ
101. こういった文化形成は各種定義・ルール・手順作成はもちろん、 プロジェクトのオーナーがいかに手厚くフォローするかが重要になります 例えば各種フローを上手く自動化できても認知されていないのでは意味がありません 必ず文化形成を念頭に入れた推進していきましょう さいごに
102. SRE Technology Map https://www.cyberagent.co.jp/techinfo/info/detail/id=28998 お知らせ
103. お〜い磯野〜！サイバーエージェントの採用に応募しようぜ〜！ 新卒採用 https://www.cyberagent.co.jp/careers/special/students/tech/ 中途採用(エンジニア) https://hrmos.co/pages/cyberagent-group/jobs?category=1479332733224841216 お知らせ