年間1,000万件のアラートを自動処理してみた

1. 年間1,000万件のアラートを自動処理してみた講演者：福原亮（サービス基盤本部サービス運用企画部 M & O サービス開発課）

2. 4 IIJの現状 IIJ GIOの実績顧客数 1,520社監視ノード数 10万台年間アラート総数 1,000万件 94％ 48％アラート処理人による作業自動化の躍進

3. 1000万件のアラートとは？

4. 6 ・チケット管理・手順書・システム情報 etc 異常の検知/検出異常対処分類調査/診断照合クローズ処理・フィルタリング 67％削除・イベントの記録・ワークアラウンドの確認・インシデントの顧客通知・監視等の障害検知・各種申告・イベントの影響確認・ナレッジの確認・復旧手順の調査/決定・対応方針を顧客へ報告・復旧手順の実施・対応経過/結果顧客報告・復旧確認・対応経過/結果の記録・ナレッジの更新・ワークアラウンドの作成・フィルタリング 30％削除・オペレーション 0.3％・エンジニアリング 0.03％・アラート分類 3％（対処するアラート）アラートの流れ捨てられるアラート達

5. 7 宝の山はごく一部・一般論として必要な監視に絞る不要なアラートは監視システムで除外・実態は不安なのでいろいろ監視しておく作業中の監視を止めない・結果滝のように流れ続けるアラート確認するも問題なしとしてクローズ人手不足になるのは明らかでは？必要なアラートは3％？

6. 8 自動アラート処理機構どうせ捨てるなら機械に任せるオペレーション対応や、自動処理を必要としないアラートを自動フィルタリングする機能要否判定重複排除自動処理瞬間的に同一サーバから大量発生した同事象のアラートを、5分単位で自動でたばねる機能自動電話、自動メール通知を行い、チケットの自動起票とステータスを更新する機能  本番リリース前アラート  メンテナンス時アラート  ワーニングメッセージ  データベース障害  アプリケーション障害  頻繁なステータス更新  初報通知（電話＆メール）  チケットの起票  自動クローズ想定シーン想定シーン想定シーン

7. 使われない手順

8. 10 手順書の実態解明・作成された手順書を分析 UNIXプロセス起動、Winサービス起動この2つが全体の7割という悲しい現実・手順は必要だが UNIX系はスタートスクリプトを叩く Win系は起動ボタンをポチ・これは本当に必要か？手順は当然必要ドキュメントで作る価値はあるか実態を探る手順書イメージ

9. 11 使われた手順の分析・1ヶ月間で実行した手順書 180種類の手順書 24,000回の実施回数・登録されている手順書数万手順書 ※オペレーションアラートは数万件・使われる手順はごく一部上位10手順で60% 実施状況を掘り下げる手順書カテゴリ実施数

10. 12 いったい誰得なのか・上位10手順を見るとほとんどが有人連絡（電話orメール）特定の手順・オペレーションには違いないがこれは有人対応は必要か？苦労して作った手順はいつ使われるのか？・手順書に必要な情報整理連絡先情報、ログイン情報他常に整合性を取るのは至難の業手順管理コストの増加実施内容をみてみるとある月の手順上位

11. 増え続けるシステム

12. 14 国内企業のクラウド動向オンプレ志向は根強い自社拠点内データセンター国内のデータセンター事業者海外のデータセンター事業者国内のクラウド事業者海外のクラウド事業者現在利用中（今後は廃止予定）現在利用中で今後も継続予定 63％ 51％現行システムの稼働環境利用していない（今後利用予定）利用していない（今後も利用しない）分からない出典： ITR 2016年11月「IaaS調査」

13. 15 国内クラウドサービス市場規模国内PaaS／IaaS市場は今後も拡大 1,115 1,352 1,680 2,050 2,460 2,878 3,252 2013年度 2014年度 2015年度 2016年度 2017年度 2018年度 2019年度国内PaaS/IaaS市場規模推移および予測（単位：億円）出典： ITR「ITR Market View：クラウド・コンピューティグ市場2016」 CAGR（2013～2019年度） 19.2％

14. 16 IIJユーザのマルチクラウド活用状況７割以上のユーザが他クラウドサービスと併用 33% 22% 16% 13% 6% 5% 5% 5% 5% 5% 34% AWS Microsoft グーグル NTT-com ニフティ GMOクラウド IDCフロンティアビットアイル KDDI セールスフォースその他 IIJ GIOのみ単独利用中 27% 他クラウド併用中 IIJ GIOユーザの他クラウド活用状況 73％出典： 2015年「IIJ GIOカスタマーサーベイ」

15. 17 システム運用の課題サイロ化が招く悲劇サイロ化属人化運用負荷増アジリティ低下運用運用運用運用課題オンプレミス IIJ GIO (IaaS) Azure (IaaS) AWS (IaaS)

16. 18 増え続けるシステム運用レベルクラウドB クラウドC オンプレミスA オンプレミスB 統合運用には程遠い 追いつかないスキルセット 日々更新されるシステムクラウドA 不均衡なサービスレベル

17. 課題の整理

18. 20 運用現場には課題が山積・不必要なアラート現場に必要なアラートは3%程度仕分けは重要だが人手処理は限界機械処理で十分では？・使われない手順の山電話/メールオペレーションは有人が必須なのかよく使われる手順はごく一部自動化すべきは全てではない・増殖するシステム現場にとってクラウド運用は受難の道オンプレ、IaaS、PaaS、SaaS、オフィスIT、、、運用のアジリティーとはいったい

19. IIJの出した答え

20. 22 効率化手間を“自動化“してシステム運用を効率化自動化による効率化統合監視大量アラート自動フィルター原因の調査自動オペレーションチケットに実行結果を記録

21. 23 バックエンドの全容製品利用自社開発アラート中継アラート転送自動オペレーションチケッティング監視 API ホワイトリスト重複判定抑止リスト手順書紐付け大量アラート判定アラート転送(チケット発番) メール通知電話通知チケット管理スクリプト/ジョブ起動メール取込ジョブ管理チケット管理（社内）ユーザインタフェース統合ポータルコントロールパネルバックエンド解説 API

22. 24 バックエンド解説（アラート）アラート監視 API メール取込ジョブ管理多様なアラート取得方式・監視弊社提供のSaaS型監視サービス・ジョブ管理弊社提供のSaaS型ジョブ管理サービス・API OSS、監視製品とのAPI受付インタフェース・メール監視が入り込めないデバイスからのメール取込他社サービスの障害/メンテ等のメール取込

23. 25 バックエンド解説（中継）フィルタリングのコア機能・ホワイトリスト特定ノード、監視項目単位で許可リスト（マスター）・重複判定 5分単位でスパイクアラート集約・抑止リスト一定期間のみの不許可リスト（トランザクション）・手順紐付け HTLM手順自動生成中継ホワイトリスト重複判定抑止リスト手順書紐付け

24. 26 バックエンド解説（アラート転送）ちょっとした重要な前処理・大量アラート判定案件単位で一定の閾値を超えた場合に転送を保留ノード単位で発生アラートをサマリーして自動メール・アラート転送チケットを転送してチケット番号を発版案件の状況を鑑み転送スレッドを振分転送スレッド内で転送速度制御アラート転送大量アラート判定アラート転送(チケット発番)

25. 27 バックエンド解説（自動オペレーション）自動化オペレーションの心臓・メール通知監視条件毎に指定連絡先グループにメール・電話通知監視条件毎に指定連絡先グループに電話カレンダー、時間帯設定、輪番制御受諾者情報を通知結果メール・スクリプト/ジョブ起動監視条件毎に指定スクリプト/ジョブを自動実行（ssh接続）実行結果の通知メール/電話チケット機能に実行結果アップデート ※後ほどデモ致します自動オペレーションメール通知電話通知スクリプト/ジョブ起動

26. 28 バックエンド解説（チケッティング）オペミスを防ぐインシデント管理・チケット管理発生インシデントは自動起票利用者自身で新規チケット発行可能お客様用のインシデント、リクエスト、タスク管理機能メール作成、リマインダー、ファイル保管、ビュー管理 ※後ほどデモ致します・チケット管理（社内）現時点の社内管理用のチケット管理基盤チケッティングチケット管理チケット管理（社内）

27. 29 バックエンド解説（ユーザインタフェース）マルチデバイス対応WEBとAPI ・統合ポータルアラート発生状況や各種設定の窓口サイトマルチデバイス、日本語/英語対応 ※後ほどデモ致します・コントロールパネル監視、ジョブ、運用等のサービス設定用コンパネ・API チケット、コンパネ類のweb-UIと同等のAPIインタフェースユーザインタフェース統合ポータルコントロールパネル API