SERVICE # ITソリューション事業 ／ ITインフラ・クラウド ![](/media/newsite-career-infra.png) ## お客様のクラウドとインフラの運用監視を 技術者が支援します。 24 時間 365 日の監視と一次対応から、二次対応までを担います。同じエラーや誤検知を放置せず、検知ルールと仕様書を見直して、監視の精度を上げていきます。 MANAGED SERVICES ## 運用監視・運用支援のサービス - ![](/media/infra-cloud.svg) ### クラウドマネージドサービス AWS や Azure などの主要なクラウドサービスに対応し、24 時間 365 日体制での運用監視を提供します。 - ![](/media/infra-security.svg) ### セキュリティマネージドサービス ファイアウォールや UTM の運用、不正侵入検知・防御システム（IDS/IPS）、Web サイトの改ざん検知、メールセキュリティ対策などを提供します。 - ![](/media/infra-kitting.svg) ### 情シス対応キッティング支援 システム監視、障害対応、社内ヘルプデスクの運営、PC のキッティングなど、専任の担当者が IT に関する課題の解決をサポートします。 - ![](/media/infra-outsourcing.svg) ### ITアウトソーシング ネットワークや IT 機器の管理、セキュリティ対策などの業務を代行し、社内の IT リソース不足を補います。 - ![](/media/infra-integration.svg) ### ITインフラインテグレーション 運用監視を前提に、ネットワーク技術、IoT、セキュリティ要件に対応したインフラの設計・構築を行います。 OPERATIONS & MONITORING ## 運用監視の業務 典型的な構成と運用監視で担う業務です。当社は、一次対応と二次対応の両方を担います。 監視する対象サーバー・ネットワーク機器・クラウド監視ツールエージェント・SNMP で集め、しきい値を超えたらアラートを出す（例 Zabbix）一次対応チーム24 時間 365 日。仕様書に沿って確かめ、決められた対処をする。お客様へ初報二次対応チーム技術者。原因を調べて復旧し、お客様へ続報。障害報告書と仕様書をつくる保守ベンダー・メーカー・お客様の開発チーム製品の不具合や設定の変更を依頼する→→エスカレーション→三次対応→チケット管理アラートをチケットに起こし、誰が受け、いつ上げ、いつ閉じたかを残す（例 Redmine・Backlog・ServiceNow）お客様への連絡一次対応チームが決められた時間内に初報、二次対応チームが続報と障害報告書仕様書アラートごとの確認と対処の手順。一次対応チームが使うログ各サーバーの中にある。ネットワーク機器のログは syslog サーバーに集めることが多い監視する対象サーバー・ネットワーク機器・クラウド ↓監視ツールエージェント・SNMP で集め、しきい値を超えたらアラートを出す（例 Zabbix） ↓一次対応チーム24 時間 365 日。仕様書に沿って確かめ、決められた対処をする。お客様へ初報エスカレーション ↓二次対応チーム技術者。原因を調べて復旧し、お客様へ続報。障害報告書と仕様書をつくる三次対応 ↓保守ベンダー・メーカー・お客様の開発チーム製品の不具合や設定の変更を依頼するチケット管理アラートをチケットに起こし、誰が受け、いつ上げ、いつ閉じたかを残す（例 Redmine・Backlog・ServiceNow）お客様への連絡一次対応チームが決められた時間内に初報、二次対応チームが続報と障害報告書仕様書アラートごとの確認と対処の手順。一次対応チームが使うログ各サーバーの中にある。ネットワーク機器のログは syslog サーバーに集めることが多い 1. 01 ### 監視・検知 24 時間 365 日、Zabbix などの監視ツールで、サーバー・ネットワーク機器・クラウドの状態を見て、アラートを受け、チケットに起こします。 2. 02 ### 一次対応と初報 一次対応チームが、仕様書に沿って状況を確かめ、決められた対処（サービスの再起動など）を行います。決められた時間内に、お客様へ初報を入れます。 3. 03 ### エスカレーション 仕様書で対処できないものは、一次対応チームから二次対応チームへ上げます。製品の不具合や設定の変更が要るものは、保守ベンダー・メーカー・お客様の開発チームへ依頼します（三次対応）。 4. 04 ### 二次対応と報告 二次対応チームが原因を調べて復旧し、お客様へ続報を入れます。原因と再発防止策は、障害報告書にまとめます。 5. 05 ### 定期作業 バックアップの確認、証明書の更新、パッチの適用、ディスク容量の確認を行います。 6. 06 ### 月次の報告 アラートの件数と傾向、対応の内容、改善の提案を報告します。 AS-IS / TO-BE ## あるべき運用監視の体制 運用監視でよく起きているのは、同じエラーや誤検知、同じエスカレーションが放置されたままになることです。アラートを閉じて終わりにせず、繰り返すものを検知ルールと仕様書の見直しにつなげる体制をつくります。 AS-IS ### 同じエラーと誤検知が、 放置されている 01アラートが鳴る同じエラー・誤検知02一次対応が確かめる「いつものこと」03何もせずに閉じる理由は残らない何も変わらない翌日また同じアラートが鳴る - ×同じアラートが毎日のように鳴り、一次対応チームが確かめては閉じている - ×誤検知が多く、本当に見るべきアラートが埋もれる - ×仕様書にないものは二次対応チームへ上がり、二次対応チームが同じ対応を繰り返している - ×閉じた理由が残らないので、検知ルールも仕様書も変わらない TO-BE ### 一次対応チームへの移譲と、検知ルールの改善を、 2 つのループで回す MONITORING CYCLE 運用監視サイクル：同じアラートを繰り返さない エスカレーション01　監視ツール検知アラートが鳴る03　二次対応チーム二次対応原因の調査・復旧04　二次対応チーム仕様書を作り込む一次対応チームへ移譲05　一次・二次振り返り閉じたチケットを数える06　二次対応チーム改善誤検知の検知ルールを直す02　一次対応チーム一次対応仕様書どおりに確かめるPERIODIC定期のループ閉じたチケットを振り返り、ルールを直すEVERY INCIDENT対応のたびのループ仕様書にして一次対応チームへ移譲する - 日々の対応 - 対応のたびのループ - 定期のループ - AS-IS で抜けているところ - ✓チケットを閉じるときは、一次・二次のどちらも必ず理由を残す - ✓二次対応チームが対応したものは、判断の条件・確認のしかた・エスカレーションの条件まで仕様書に作り込み、一次対応チームへ移譲する - ✓一次・二次で閉じたチケットを定期的に振り返り、同じ理由で繰り返しているものを洗い出す - ✓誤検知は検知ルールを直す。原因がシステムにあるものは、お客様の開発担当へ修正を依頼する - ✓月次の報告では、何を直して、アラートとエスカレーションが何件減ったかを報告する WHY IT STALLS ## なぜ、このサイクルは回らないのか 課題は分かっていても、改善を担う人の手が空いていません。手が空かないから改善が進まず、改善が進まないから、さらに手が埋まります。この循環を逆に回すきっかけは、仕様書を作り込み、一次対応チームへ業務を移譲していくことです。 01二次対応チームが逼迫障害対応で手が埋まる02仕様書が作り込まれない一次対応チームへ移譲できない03同じ障害が上がり続ける二次対応チームへ悪循環抜け出す余力がない 1. 01 ### 二次対応チームの工数が逼迫している 障害対応に追われ、振り返り・仕様書への落とし込み・検知ルールの見直しに時間を割けない。 2. 02 ### 自動化のコードを書く人の手が空いていない 検知ルールの設定や確認のスクリプトは、コードを書く仕事。仕様書までは書けても、自動化で止まる。 回らない原因 AI でこうする 1. 01二次対応チームの逼迫 → 二次対応のチケットの記録から、AI が仕様書（判断の条件・確認のしかた・エスカレーションの条件・お客様への連絡の文例）を下書きする。二次対応チームは確かめて確定し、一次対応チームへ移譲する。移譲した分だけ、二次対応チームの手が空く。 2. 02コードを書く人の手が空かない → 仕様書に書いた確認のしかたを、AI が読み取りだけの確認スクリプトにする。誤検知を減らす検知ルールの変更案も、AI が書く。人はレビューして反映する。 AI が下書きした仕様書とスクリプトは、二次対応チームが確かめて確定します。AI に何を見せるかは、下の段のとおり、お客様と一緒に決めます。 AIOps × 運用監視 AIOPS FOR MONITORING ## 日々の運用に AI を入れるときは、一緒に検討します **この段で 伝えていること** 日々の運用で AI が担うのは、二次対応の記録から仕様書を下書きし、一次対応チームへの移譲を進めることです。仕様書に要るのは、どの状態なら何を確かめ、どうするかという判断の条件と手順で、本番の生のログや個人情報がなくても作れます。仕様書づくりに使う情報は、お客様の環境の中でマスクしてから AI に渡します。API の権限とマスクのルールは、お客様と一緒に決めます。本番を変える操作は、AI にはさせません。 ### マスクしてから、AI に渡す 仕様書づくりに要る情報は、お客様の環境の中でマスクしてから AI に渡します。AI が受け取るのは「低」の情報だけです。 1. 01 取り出す 監視ツールやチケット管理の API から、必要な項目だけを読み取りで取り出す（例 Zabbix の problem.get・trend.get） ↓→ 2. 02 マスクする お客様の環境の中で、決まったルールのスクリプトが、ホスト名・お客様名・担当者名・IP を記号に置き換える。対応表は環境から出さない ↓→ 3. 03 抜き取りで確かめる 最初のうちは、マスクした後の内容を人が確かめる。自由に書いた文章の漏れを見る ↓→ 4. 04 AI が下書きする 受け取るのは低の情報だけ。仕様書の下書きや、しきい値の試算をする ↓→ 5. 05 確かめて戻す 二次対応チームが確かめて確定し、記号を元の名前に戻す AI のタスク 必要な情報（元のレベル） マスクの仕方 AI が受け取るもの 繰り返しているアラートを洗い出す アラートの履歴、チケットの閉じた理由（中） API で項目ごとに取り出し、ホスト名を記号に置き換える 低 仕様書を下書きする 二次対応のチケットの経過、今の仕様書、監視の設定（中） チケットの本文は、ホスト名・担当者名の辞書と、IP・メールアドレス・電話番号のパターンで置き換える。監視の設定はテンプレートを書き出す 低 お客様への連絡の文例を下書きする 過去の初報・続報の文面、連絡の決まり（中） お客様名・担当者名・連絡先を置き換える 低 確認スクリプト（読み取りのみ）を書く 確認のしかた、OS・ミドルウェアの種類と版、ログの形式（低） そのまま渡す 低 しきい値を変えたときの影響を試算する メトリクスの推移、誤検知だったかの記録（中） API で数値だけを取り出し、対象を記号に置き換える 低 移譲が進んだかを数える チケットの件数（低） 件数だけを渡す 低 低＝仕様書・監視の設定・公開マニュアル・件数など、そのまま渡せる情報。中＝チケット・障害報告書・構成情報など、マスクが要る情報。高＝本番の生のログ・個人情報・認証情報。高の情報は、どのタスクにも使いません。お客様に確認いただくのは、API の権限（読み取りだけ・対象のホストグループ）と、マスクのルール（何を、どの記号に置き換えるか）の 2 つです。 具体例をコードで見る具体例を閉じる 1. 01 検知 アラートが鳴る ↓→ 2. 02 対応 一次・二次対応チームが、仕様書に沿って対処する ↓→ 3. 03 振り返り 閉じたアラートと対応の記録を AI が仕分け、変更案を下書きする ↓→ 4. 04 反映 人が確かめて、検知ルールと仕様書に反映する ↺ 次のアラートは、直したルールと仕様書で扱う。回すほど、同じアラートを繰り返さなくなる 1. 01 ### 一瞬の負荷増加を障害として扱わない **これまで**CPU 使用率が一瞬 80% を超えただけで夜間にアラートが鳴り、一次対応チームが確かめて何もせずに閉じる。 **AI を組み込むと**誤検知として閉じた記録を AI が集め、「80% を超えた状態が 〇〇 分続いたら通知する」条件への変更案を下書きする。人が確かめて監視ツールに反映する。 同じ理由の誤検知が、次から鳴らなくなる # 監視ツールのトリガー条件（API サーバーの CPU）- CPU 使用率 > 80%（一度でも超えたら通知）+ CPU 使用率 > 80% が 〇〇 分続いたら通知+ # 振り返り: 一瞬の負荷増加による誤検知が続いたため 2. 02 ### 二次対応した内容を、一次対応の仕様書にする **これまで**証明書の自動更新が失敗したときの対応が仕様書になく、そのたびに二次対応チームへ上がっている。 **AI を組み込むと**二次対応の記録から、AI が仕様書への追記と確認用スクリプトを下書きする。二次対応チームが確かめて、一次対応の仕様書に加える。 次からは、一次対応チームで対処できる ## 仕様書: 証明書の自動更新が失敗したとき+ 1. 確認用スクリプトで、期限と DNS の検証状態を確かめる+ 2. 検証用レコードが無ければ再作成して 10 分待つ+ 3. 更新されない場合は、二次対応チームへエスカレーション 3. 03 ### アラートと、見るべき仕様書を対応づける **これまで**アラートの名前だけでは何が起きたかがわからず、一次対応チームがどの仕様書を見ればよいか迷う。 **AI を組み込むと**過去のアラートと仕様書から、AI がアラートごとの重大度と参照する仕様書の対応表を下書きする。人が確かめて、監視ツールの通知文に反映する。 アラートを見れば、重大度と見るべき仕様書がすぐにわかる # アラートと仕様書の対応表+ DB の応答遅延　　　　重大度: 高　仕様書: DB の応答遅延+ アクセス数の上限超過　重大度: 低　通知しない（集計のみ）+ 証明書の期限切れ間近　重大度: 中　仕様書: 証明書の更新 検知ルールと仕様書の変更は、必ず人が確かめてから反映します。本番での操作は、人の明示的な指示でのみ実行します（HITL）。内容は説明のための例です。 OTHER SERVICES ## ITソリューション事業のほかのサービス ![](/media/newsite-career-dev.png) Forward Deployed Engineer ### [▶FDE](/service/it-solution/fde) ![](/media/newsite-career-qa.png) Quality Assurance ### [▶テスト・品質保証](/service/it-solution/quality-assurance) ![](/media/newsite-contact-hero.png) ## CONTACT ご相談の内容が固まっていなくても構いません。下記のフォームからお気軽にお問い合わせください。 [▶お問い合わせ](/contact)