Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,160 views

Published on

[2017/08/31に開催した「IIJ Technical NIGHT Vol.3」の講演資料です]
IIJでは多数のシステムを運用しており、それらのシステムからは日夜数限りないアラートが発生しています。それらのアラートに対して実際に行わなければならない作業はどのようなものでしょうか?アラートの分析と、それを自動化するための手法について紹介します。
講演者:福原 亮(サービス基盤本部 サービス運用企画部 M&Oサービス開発課)

Published in: Internet

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

  1. 1. 年間1,000万件のアラートを 自動処理してみた 講 演 者 : 福 原 亮 ( サ ー ビ ス 基 盤 本 部 サ ー ビ ス 運 用 企 画 部 M & O サ ー ビ ス 開 発 課 )
  2. 2. 4 IIJの現状 IIJ GIOの実績顧客数 1,520社 監視ノード数 10万台 年間アラート総数 1,000万件 94% 48% アラート処理 人による作業 自動化の躍進
  3. 3. 1000万件のアラートとは?
  4. 4. 6 ・チケット管理 ・手順書 ・システム情報 etc 異常の 検知/検出 異常対処 分類 調査/診断 照合クローズ処理 ・フィルタリング 67% 削除 ・イベントの記録 ・ワークアラウンドの確認 ・インシデントの顧客通知 ・監視等の障害検知 ・各種申告 ・イベントの影響確認 ・ナレッジの確認 ・復旧手順の調査/決定 ・対応方針を顧客へ報告 ・復旧手順の実施 ・対応経過/結果顧客報告 ・復旧確認 ・対応経過/結果の記録 ・ナレッジの更新 ・ワークアラウンドの作成 ・フィルタリング 30% 削除 ・オペレーション 0.3% ・エンジニアリング 0.03% ・アラート分類 3%(対処するアラート) アラートの流れ 捨てられるアラート達
  5. 5. 7 宝の山はごく一部 ・一般論として 必要な監視に絞る 不要なアラートは監視システムで除外 ・実態は 不安なのでいろいろ監視しておく 作業中の監視を止めない ・結果 滝のように流れ続けるアラート 確認するも問題なしとしてクローズ 人手不足になるのは明らかでは? 必要なアラートは3%?
  6. 6. 8 自動アラート処理機構 どうせ捨てるなら機械に任せる オペレーション対応や、自動処理 を必要としないアラートを自動 フィルタリングする機能 要否判定 重複排除 自動処理 瞬間的に同一サーバから大量発生 した同事象のアラートを、5分単 位で自動でたばねる機能 自動電話、自動メール通知を行い、 チケットの自動起票とステータス を更新する機能  本番リリース前アラート  メンテナンス時アラート  ワーニングメッセージ  データベース障害  アプリケーション障害  頻繁なステータス更新  初報通知(電話&メール)  チケットの起票  自動クローズ 想定シーン 想定シーン 想定シーン
  7. 7. 使われない手順
  8. 8. 10 手順書の実態解明 ・作成された手順書を分析 UNIXプロセス起動、Winサービス起動 この2つが全体の7割という悲しい現実 ・手順は必要だが UNIX系はスタートスクリプトを叩く Win系は起動ボタンをポチ ・これは本当に必要か? 手順は当然必要 ドキュメントで作る価値はあるか 実態を探る 手順書イメージ
  9. 9. 11 使われた手順の分析 ・1ヶ月間で実行した手順書 180種類の手順書 24,000回の実施回数 ・登録されている手順書 数万手順書 ※オペレーションアラートは数万件 ・使われる手順はごく一部 上位10手順で60% 実施状況を掘り下げる 手順書カテゴリ 実施数
  10. 10. 12 いったい誰得なのか ・上位10手順を見ると ほとんどが有人連絡(電話orメール) 特定の手順 ・オペレーションには違いないが これは有人対応は必要か? 苦労して作った手順はいつ使われるのか? ・手順書に必要な情報整理 連絡先情報、ログイン情報他 常に整合性を取るのは至難の業 手順管理コストの増加 実施内容をみてみる とある月の手順上位
  11. 11. 増え続けるシステム
  12. 12. 14 国内企業のクラウド動向 オンプレ志向は根強い 自社拠点内データセンター 国内のデータセンター事業者 海外のデータセンター事業者 国内のクラウド事業者 海外のクラウド事業者 現在利用中(今後は廃止予定) 現在利用中で 今後も継続予定 63% 51% 現行システムの稼働環境 利用していない(今後利用予定) 利用していない(今後も利用しない) 分からない 出典: ITR 2016年11月「IaaS調査」
  13. 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. 14. 16 IIJユーザのマルチクラウド活用状況 7割以上のユーザが他クラウドサービスと併用 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. 15. 17 システム運用の課題 サイロ化が招く悲劇 サイロ化 属人化 運用負荷増 アジリティ低下 運用 運用 運用 運用 課題 オンプレミス IIJ GIO (IaaS) Azure (IaaS) AWS (IaaS)
  16. 16. 18 増え続けるシステム 運 用 レ ベ ル クラウドB クラウドC オンプレミスA オンプレミスB 統合運用には程遠い 追いつかないスキルセット 日々更新されるシステム クラウドA 不均衡なサービスレベル
  17. 17. 課題の整理
  18. 18. 20 運用現場には課題が山積 ・不必要なアラート 現場に必要なアラートは3%程度 仕分けは重要だが人手処理は限界 機械処理で十分では? ・使われない手順の山 電話/メールオペレーションは有人が必須なのか よく使われる手順はごく一部 自動化すべきは全てではない ・増殖するシステム 現場にとってクラウド運用は受難の道 オンプレ、IaaS、PaaS、SaaS、オフィスIT、、、 運用のアジリティーとはいったい
  19. 19. IIJの出した答え
  20. 20. 22 効率化 手間を“自動化“してシステム運用を効率化 自動化による効率化 統合監視 大量アラート 自動フィルター 原因の調査 自動 オペレーション チケットに実行結果を記録
  21. 21. 23 バックエンドの全容 製品利用 自社開発 アラート 中継 アラート転送 自動オペレーション チケッティング 監視 API ホワイトリスト 重複判定 抑止リスト 手順書紐付け 大量アラート判定 アラート転送(チケット発番) メール通知 電話通知 チケット管理 スクリプト/ジョブ起動 メール取込ジョブ管理 チケット管理(社内) ユーザインタフェース 統合ポータル コントロールパネル バックエンド解説 API
  22. 22. 24 バックエンド解説 (アラート) アラート 監視 API メール取込ジョブ管理 多様なアラート取得方式 ・監視 弊社提供のSaaS型監視サービス ・ジョブ管理 弊社提供のSaaS型ジョブ管理サービス ・API OSS、監視製品とのAPI受付インタフェース ・メール 監視が入り込めないデバイスからのメール取込 他社サービスの障害/メンテ等のメール取込
  23. 23. 25 バックエンド解説 (中継) フィルタリングのコア機能 ・ホワイトリスト 特定ノード、監視項目単位で許可リスト(マスター) ・重複判定 5分単位でスパイクアラート集約 ・抑止リスト 一定期間のみの不許可リスト(トランザクション) ・手順紐付け HTLM手順自動生成 中継 ホワイトリスト 重複判定 抑止リスト 手順書紐付け
  24. 24. 26 バックエンド解説 (アラート転送) ちょっとした重要な前処理 ・大量アラート判定 案件単位で一定の閾値を超えた場合に転送を保留 ノード単位で発生アラートをサマリーして自動メール ・アラート転送 チケットを転送してチケット番号を発版 案件の状況を鑑み転送スレッドを振分 転送スレッド内で転送速度制御 アラート転送 大量アラート判定 アラート転送(チケット発番)
  25. 25. 27 バックエンド解説 (自動オペレーション) 自動化オペレーションの心臓 ・メール通知 監視条件毎に指定連絡先グループにメール ・電話通知 監視条件毎に指定連絡先グループに電話 カレンダー、時間帯設定、輪番制御 受諾者情報を通知結果メール ・スクリプト/ジョブ起動 監視条件毎に指定スクリプト/ジョブを自動実行(ssh接続) 実行結果の通知メール/電話 チケット機能に実行結果アップデート ※後ほどデモ致します 自動オペレーション メール通知 電話通知 スクリプト/ジョブ起動
  26. 26. 28 バックエンド解説 (チケッティング) オペミスを防ぐインシデント管理 ・チケット管理 発生インシデントは自動起票 利用者自身で新規チケット発行可能 お客様用のインシデント、リクエスト、タスク管理機能 メール作成、リマインダー、ファイル保管、ビュー管理 ※後ほどデモ致します ・チケット管理(社内) 現時点の社内管理用のチケット管理基盤 チケッティング チケット管理 チケット管理(社内)
  27. 27. 29 バックエンド解説 (ユーザインタフェース) マルチデバイス対応WEBとAPI ・統合ポータル アラート発生状況や各種設定の窓口サイト マルチデバイス、日本語/英語対応 ※後ほどデモ致します ・コントロールパネル 監視、ジョブ、運用等のサービス設定用コンパネ ・API チケット、コンパネ類のweb-UIと同等のAPIインタフェース ユーザインタフェース 統合ポータル コントロールパネル API

×