概要

昔々データセンターの運用管理をしており、1つの機器の設定ミスでかなりの影響を与えてしまうような結構シビアな環境を運用していたことがあります。その中での安全管理を基準にしたシステム運用について書きたいと思います。題名にある通り、工事系（電気通信主任技術者・電気通信工事担任者）や情報処理試験を取得してみて試験内容から学習(再認識)したことなどを記載します。なお学習した内容に記載したものは、既に実施していたもの・新規に取り入れたもの・検討中だったものです。情報処理試験についても安全管理が範囲に含まれていますがどちらかというと（ITILをベースにした）管理のプロセスに主眼が置かれている気がします。（ITサービスマネージャー試験）

ソフトウェア層の運用の変化

昔はWindows Serverパッチを当てるとなると大変な作業でした。仮想化、クラウドが当たり前になりパッチ適用前にスナップショットを取得してすぐに戻す。さらにはイミュータブルインスラストラクチャという概念ではシステムに変更を加えません。例えばパッチ適用済みの新しいサーバーを用意してDNSの向き先変更後に古いサーバを捨ててしまう運用です。また、ChefやAnsibleなどのIaCツールの利用により、自動化、一括変更が可能となり、手順書ベースの作業が大分減りインフラの運用も楽になりました。

物理層の運用の変化

物理層も進化はしています。例えば仮想化を例にすると昔からの主流はサーバ〜ストレージスイッチ〜ストレージの3Tire構成でしたがこの構成だとストレージやサーバの増設に少々手間がかかります。ストレージ仮想化の技術の発展と共に（確か10年位前に）コンバージドインフラストラクチャー（HCI）が出て大分普及しました。上記3Tire構成が2Uのサーバの中に収まっておりネットワークの複雑性が解消され、機器増設なども簡単に出来るようになりました。色々と進化はしているもののデータセンターの仮想化基盤、コアネットワークの運用はシステム障害の影響が非常に大きく、特に物理層に関しては確実に人の手が必要な作業が発生するため、安全管理および変更管理の確実性が重要となります。

工事系資格で学んだもの

電気通信主任技術者・電気通信工事担任者という工事系の資格を以前取得したのですが、こちらの試験では安全管理が項目に含まれています。下記資格の勉強の中で出てきた主な安全管理の概念です。

ハインリッヒの法則

1件の重大事故の背後には29の軽微な事故があり、その背景には300のヒヤリ・ハットが存在するというものです。
重要なのはヒヤリハットを共有し対策をおこなっていくことで重大事故を防いでいくことです。また、さらに重要なのは人を責めたり報告しずらい組織文化を作ってはいけません。そのような状況だと誰も報告をしなくなってしまいます。これは障害管理やポストモーテムと考え方は同様です。

危険予知訓練（KYT）

厚生労働省の職場の安全サイトに記載がありますが、置かれた状況からどのような危険があるかを話し合い発生しうる状況、対策などを考えます。
これだとイメージが掴みづらいのでITを例にするとデータセンターのディストリビューションスイッチに一つ別のスイッチを接続する作業を想像します。起こりうる事態としてはブロードキャストストームが発生してネットワークがループ、大規模なネットワーク通信が発生し複数顧客のシステム断などが想像出来ます。LANケーブルを接続するという一つの作業の裏に最悪どんな事態が発生するかを考え必要な対策や体制、作業時間、タイミングやリカバリプランなどを決定します。

ツール・ボックス・ミーティング(TBM)

作業の開始前に行う打ち合わせのことです。道具箱（ツールボックス）の近くで行われることからこの名前です。
ITを例にするとネットワーク機器の設定変更作業をする際はにメンバーで集まって打ち合わせをします。（KY（危険予知）ミーティングと呼ぶこともあります。）今から行う作業内容の共有や作業の前提項目を満たしているかなどを確認します。

情報処理試験で学んだもの

運用といえばITサービスマネージャー試験（落ちました）です。この試験はITILの考えがベースになっていると思います。また障害はシステム変更の際に最も発生しやすいことから変更管理について取り上げます。

変更管理

全ての変更は変更諮問委員会 (CAB) で承認される必要があります。CABですが様々な視点・役割の人を入れると良いと思います。例えば技術者だけではなくサービス主管の部門に入って貰えばよりユーザ視点での判断が出来ます。また、変更には下記３種類あります。

標準的な変更
繰り返し定常的に発生する作業です。例えばネットワーク内に仮想マシンが増えてファイアウォールのルール追加が必要な場合を考えます。この種類の変更は毎回承認をもらうのではなく、汎用的な手順を作成しその手順に対して承認をもらいます。以後、汎用的な手順に変更がない限り追加の承認は不要で作業します。標準的な変更は出来れば自動化したいものです。
通常の変更
ネットワーク構成の変更など予定された通常の変更です。CABによりリスク評価、承認完了後、実施します。
緊急の変更
障害発生時や緊急のパッチ適用などが必要な場合です。CABにより承認を得ますが、標準的な変更と比べ迅速に行う必要があります。緊急時、CABメンバーとスムーズに連絡が取れるか等、未確定な要素があるのでDR（災害対策）と同様に一部権限移譲などより柔軟な運用が必要であると考えています。

その他

表題の資格で学んだものではないですが追加

手順書

手順書の中にリカバリ判断ポイントを作ります。例えばリカバリポイントとして、対象機器全台にPingが通る、対象機器でアラートが上がっていないなどです。リカバリ判断ポイントに応じたリカバリ手順を事前に作成します。

暗黙の確認項目のリスト化

例えば仮想マシンを新規に追加する際にPingを打って応答がないか確認する、追加するストレージの空き容量に問題がないか確認するなどは当然実施すると考え、手順書に書かない場合が考えれれます。必ず実施するリストを作成し個別手順書とセットで用意しておきます。

作業について

手順書をベースにダブルチェックを行いながら、完了した作業についてはチェックおよび時間の記録を行います。また作業中は指差し確認、しっかりと声を出して確認することが重要です。

自動化について

下記は余談です。サーバー関連、定常業務などはスクリプトなどで自動化が進んでいきましたが、物理層、ネットワーク機器についてはなかなか進めることが出来ませんでした。

物理機器の障害検知

機器に異常が発生した際の検知について、サーバーの管理ツール（HPではILO、DELLではiDracなど）の使用やネットワーク機器ではトラップと飛ばせばある程度発生と同時に検知は出来ます。ただし機器によっては管理ツールが利用できなかったり、ネットワーク上の制約で通知機能が利用出来ないことから多くのデータセンターでは1日数回目視での確認を実施しています。しかし、機器によりランプのエラー表示は異なり、台数もかなりの数があることからエラーの見落としの可能性があります。この分野ではサーバラックにカメラを設置し機器の状態に変化があった際に自動的に管理者に通知する製品などもあります。しかし費用対効果の観点から導入は断念しました。

ネットワーク機器の自動化

AnsibleにはCisco（IOS）やJuniper（Junos）に対応したモジュールがあり、対象全機器に対してConfigの設定や取得をすることが可能です。しかしながらデータセンターのコア層やディストリビューション層に対する一括変更は頻度が少ないのとやっぱりこれを一括でやるのは怖い。。ことからここは断念。Configや機器の状態取得のみをAnsibleとAWXで自動取得するのみとしました。アクセス層のスイッチが多い環境ならAnsibleを使っていたかもしれません。

まとめ

運用についてまず考えるのは自動化です。しかし人の手がかかる作業は必ず残ります。システム化で解消出来ない場合は運用フローの設計やルールを確実に実施するための仕組みが必要となります。