目次

  1. トップ01–03
    1. 名前
    2. 約束
    3. 事業
  2. Core04
    1. 設計Design
    2. 構築Build
    3. 運用Operate
      1. 監視O-01
      2. 障害対応O-02
      3. 保守O-03
      4. 変更管理O-04
      5. バックアップO-05
      6. 改善O-06
  3. Aidle05
  4. 用語と資料06
    1. 参照した主な資料
  5. 会社情報・お問い合わせ07

球体や文字の動き、流れる帯を止めます。

用語

Aidle Core / AI Guide

Aidle Coreに聞く

会社や事業について、公開情報をもとにAIがご案内します。

AIの回答には誤りが含まれる場合があります。詳しい内容は各ページでご確認ください。このチャットでお問い合わせの送信・応募受付は行いません。

入力内容と直近の会話は、回答生成のためCloudflareに送信されます。氏名・連絡先・機密情報は入力しないでください。当社では会話を保存しません。800文字まで。

運用Operate

止まっても戻せるように、備え続ける。

ITインフラの運用は、稼働を始めたシステムを、毎日安定して動かし続ける工程です。変化に気づくための監視、障害からの復旧と再発防止、更新や脆弱性への対応、変更の管理、バックアップ、そして改善。何も起きていない時間に、次に起きることへの準備を整えておく。この備えを、私たちは idle という名前に込めています。

異変に気づく監視

システムの状態を、決めた項目と深さで見続けます。

監視には、何を見るかによっていくつかの種類があります。機器が応答しているかを見る死活監視、ログに出たエラーをとらえるエラー監視、CPU・メモリ・ディスク・帯域の使用状況を見るリソース監視、応答時間や処理量を見るパフォーマンス監視です。何を、どの深さで見て、どこへ知らせるかを先に決めます。

SRE(Site Reliability Engineering)は、システムを安定して動かし続けるための運用の考え方で、Googleが書籍にまとめて公開しています。その書籍は、人を呼び出すアラートを、次のような状況に絞るべきだとしています。すぐに対応が必要で、実際に打てる手があり、利用者に影響が出ている、または出ようとしている状況です。

鳴ったときに意味のあるアラートを目指し、知らせる基準にする値(しきい値)は、運用しながら見直します。監視の結果は、要件で決めた稼働率などの目標とも照らし合わせます。

  • 監視の設定
  • アラートの一覧

まず戻し、繰り返さない障害対応・問題管理

障害が起きたら、原因の究明より先に、サービスを元に戻すことを優先します。

ITサービスマネジメントの考え方をまとめた枠組みに、ITIL 4があります。ITIL 4では、サービスが予定外に止まったり品質が落ちたりすること(インシデント)が起きたとき、できるだけ早く通常の状態に戻して悪影響を抑える取り組みを、インシデント管理と呼んでいます。

サービスを早く元に戻すために、一般的な障害対応では、はじめに影響の範囲と発生箇所を見きわめます(一次切り分け)。最初に対応した担当者だけでは解決できないと判断したら、あらかじめ決めた連絡体制に沿って、早めに上位の担当者や専門のチームへ相談し、対応を引き継ぎます(エスカレーション)。

復旧とあわせて、インシデントの原因や、原因になりうるもの(ITIL 4では、これを「問題」と呼びます)を突き止め、取り除く対策を進めます。すぐには直せない場合は、まだ直せていない原因(既知のエラー)と、影響をひとまず避ける方法(回避策)を記録して、同じ障害が起きてもすぐに対応できるようにします。こうしてインシデントの起こりやすさと影響を小さくしていく取り組みが、問題管理です。個人を責めるのではなく、手順や仕組みの側に対策を求めます。

  • 障害記録
  • 障害報告書
  • 再発防止策

安全な状態を保つ保守・脆弱性対応

障害が起きる前に、弱点をふさぎ、期限切れやサポート終了に先回りします。

保守の主な仕事は、OSやミドルウェアの更新プログラム(パッチ)の適用、脆弱性への対応、証明書の更新、そして機器やソフトウェアのサポート終了時期を確かめたうえでの入れ替えの計画です。

米国国立標準技術研究所(NIST)の文書(SP 800-40 Rev. 4)は、パッチ管理を予防保守の重要な要素と位置づけています。

どの脆弱性から対応するかは、深刻度の点数(CVSS)だけでなく、実際に悪用されているかどうかや、対象の環境への影響もあわせて判断します。更新は検証環境で試してから、影響の少ない時間帯に手順書どおりに行います。

  • 保守計画
  • 作業記録

変更を管理する変更管理・構成管理

設定の変更は、記録とレビューを経てから行います。

設定変更やパッチの適用は、障害のきっかけにもなります。何を、なぜ、いつ変えるのか。影響の範囲と元に戻す手順を用意し、承認を得てから作業します。

ITIL 4では、この実践を「Change Enablement」と呼んでいます。その目的は、リスクをきちんと評価したうえで変更を承認し、実施の予定を管理することで、成功する変更を増やすことです。

変更を止めるためではなく、安全に通すための管理です。いまの構成を正しく記録し続けることも大切です。記録と実物がずれていると、障害時の切り分けも、変更の影響の確認も難しくなります。

  • 変更申請・変更記録
  • 構成管理表

戻せる状態を残すバックアップと復旧

データと設定を定期的に保存し、本当に戻せることを確かめます。

設計で定めた目標復旧時点・目標復旧時間(RPO・RTO)を守れるよう、必要な頻度でバックアップを取り、残す数(世代)と保管場所のルールに沿って運用します。

バックアップには「3-2-1ルール」という考え方があります。元のデータを含めて3つのコピーを持ち、2種類の媒体に保存し、そのうち1つを施設の外に保管する、というものです。米国の政府機関CISA(サイバーセキュリティ・インフラストラクチャセキュリティ庁)のサイトで公開されている資料「Data Backup Options」(2012年)も、この考え方を紹介しています。

IPAの「ランサムウェア被害から学ぶ教訓集」は、攻撃者に汚染された可能性のあるバックアップは復旧に使えないと指摘しています。教訓集によれば、少なくとも侵入が始まる前に取ったバックアップは安全と考えられます。そのため、侵入の開始時期をたどれるようログを残し、どの時点まで戻せば安全かを判断できるようにしておくことが大切だとしています。

そのうえで、復元の手順を定期的に試し、決めた時間のうちに、決めた時点のデータまで戻せるかを確かめます。

  • バックアップの記録
  • 復旧手順書

手間を減らし続ける改善と自動化

運用で見つかった手間や無駄を、少しずつ減らします。

SREの書籍は、次のような作業を「トイル」と呼び、減らすべき対象としています。手作業で、繰り返し発生し、自動化でき、割り込みへの対応が中心で、長く残る価値を生まず、サービスの成長に比例して増えていく作業です。

改善では、繰り返す作業を自動化し、アラートを見直し、手順書を更新し、使用量の推移から増強を前もって計画します(キャパシティ管理)。運用で集まった気づきは、次の設計に返します。AIの活用も、お客様の情報の取り扱いルールを守ることを前提に、この改善の中で試していきます。

  • 改善の記録
  • 更新した手順書
設計 構築 運用 改善
この循環を繰り返すたびに、インフラは少しずつ強くなります。

このページで触れた資料へのリンクは、「用語と資料」の「参照した主な資料」にまとめています。