インフラエンジニアは何をやっているのか
「インフラエンジニア 」の業務範囲が広すぎる！
ということで、「そもそもインフラとはなんぞや」というところから掘り下げて行こうと思います。
コンピュータシステムにとってインフラとは
そもそもコンピュータシステムにとってインフラとは何だろう？
インフラというのもともと、サービスや機能を提供するための土台を指す。
ことにコンピューターシステムにおいては以下のような要素が「システムインフラ」と呼ばれる。
- ハードウェア
- ネットワーク
- オペレーションシステム
- ミドルウェア
システムインフラでは利用者が不都合なくサービスを利用するために、安定したサービスを提供すること、また障害に備えた仕組みづくり、将来の拡張性などが求められる。
実際に参加するプロジェクトは保守や運用から入り、手順書作成したりレビューをしたりというところから始まる。そして、ある程度仕事内容を理解してから設計を任せてもらうことが多いと思う。（設計できるまでにだいたい2、3年かかる？）
インフラエンジニアが担う設計範囲
そしてインフラエンジニアが担う設計範囲は以下の3点。
これらの設計に基づき、以下のような製造、テスト、運用保守、監査といった業務が発生する。
製造工程
前工程での設計に従って、システム環境を構築するのがインフラでの製造工程に該当する。具体手にはOSのインストールやミドルウェアの設定など。
システム設計の内容通りに環境構築を行うため、まずは構築手順書や構築後の検証手順書を作成する。
テスト工程
テスト工程では、構築したシステム上で開発したOS、ミドルウェア、アプリケーションなどが要件定義、設計通りに正しく動作することを確認する。
テスト工程には、以下のようなテストがある。
単体テスト
プログラムを構成する部品ごとに、動作確認をするテストのこと。インフラエンジニアによる単体テストでは、サーバ単体でのOS、ミドルウェアによる機能確認を行う。
結合テスト
部品間の接続（インターフェース）の動作確認をするテスト。インフラエンジニアによる結合テストでは、サーバ間のOS、ミドルウェアの機能間連動確認を行う。例えばWebサーバとDBサーバを連携させるようなテスト。
システムテスト
本番運用を想定したシステム全般に関するテスト。本番運用を想定するため、日次、週次、月次、年次に発生するシステムの運用を実際に稼働させて動作確認や検証などを行い、システム要件が満たされているかを確認する。
例えば、以下のようなことを検証する。
・ピーク時のレスポンスおよびスループットが要件を満たしていることを検証
→高負荷状態でもシステムリリースに問題ないか
・障害発生時や災害発生時のシステム切替・回復・業務復旧の一連のプロセスを検証
→機能および手順の妥当性・通常日、特定日などイベントを狙った実際の稼働シナリオテストを検証
→実際の稼働時と同じ状況下で業務設計を行い、機能面や性能面での問題がないか
運用テスト
システム運用部が実際のオペレーションマニュアルに基づき、本番同様の動作環境と運用体制でシステム全体の機能や運用についてテストを実施する。
ユーザ受け入れテスト
導入後のユーザ業務利用を想定したテスト。
業務利用ユーザが業務要件を充足しているかを確認して行う。また業務フロー、事務手続きと整合性が取れているかの最終確認も打鍵して行う。
運用保守工程
システム稼動の開始後、システムの安定稼動を目的にシステムの運用保守を行う。
運用保守業務の代表例は以下の通り。
監視運用
障害や不具合の早期発見を目的に行う運用。
以下の5点を行う。
プロセス監査
サービス継続のためにサーバ上で稼動し続ける必要のある特定のプロセスが支障なく稼動しているかを確認する。例えばWebサーバであればhttpプロセス、APサーバであればWebアプリケーション・サーバのプロセス（Javaプロセス）が監査対象のプロセスとなる。
メッセージ監査
エラーログ監査のこと。システムに異常が発生した時、OSや製品にエラーメッセージが出力されるので、これを定期的に監視する。
リソース監査
システムを構成するサーバのCPU、メモリ、ディスクなどの各種リソースが適切に使用されているかどうかを監視する。監視基準として、一般的には各リソースの使用率が使われる。例えばCPUであれば、要件定義の段階で「CPU使用率が＠%以下となるシステム構成を採用する」といった形で定義されるので、この値を越えることがないように監視を行う。
そして監視結果として、ある通知が行われた場合、この通知が一時的なものだったのか、継続的に発生する可能性があるものなのかを見極める。
ハードウェア監査
通常、ハードウェアになんらかの障害が発生した場合、その障害発生を示すログファイルが出力される。ハードウェア監査では、これらログファイルにエラーが出ていないことを継続的に確認する。
ジョブ監査
バッチ処理が予定した時間に終わっている、あるいは予定された時刻までに完了している、といった定期的な実施処理が想定の範囲内に開始、完了しているかを監視する。
実行すべきジョブが全て正常に実行され、正常に終了されているかの監視を行うと共に、遅延が生じていないかを確認する。
バックアップ運用
バックアップにはシステムバックアップとデータバックアップの2種類ある。
システムバックアップはOSを含むイメージバックアップ。システム障害からの復旧を目的としている。
データバックアップはデータ破損や紛失に備えて復旧するためのバックアップ運用。
なぜバックアップが必要なのか？
業務で使用するデータは、業務サーバが使用している「物理的なディスク上」に書き込まれています。しかしながら、残念なことにディスク装置は10年利用出来るものではありません。
ディスクは磁性体がついた円盤をモーターで回転させながら利用するストレージ媒体であるため、必ずいつかは壊れてしまいます。
さらに、予測できない不慮の事故のためにディスク装置が壊れてしまう可能性もあります。ディスク装置が壊れていなくてもOSが起動しなくなる可能性もあるのです。
HDDはディスクを物理的に円盤を回すので衝撃で傷ついていつか壊れてしまうし、SSDのフラッシュメモリも年々劣化するらしい。
こうしたディスク装置はバックアップが必要。
ウイルス対策運用
アンチウイルスソフトの導入やパターンファイルと呼ばれるワクチンソフトを定期的に更新するなど。
バッチ、ファームウェア運用
ウイルス対策同様、システムに悪影響を及ぼす可能性を排除するためにセキュリティパッチやファームウェアの適用を定期的に行う。
自動化運用
定期的なサーバの再起動やログ転送などを自動で運用する仕組みのこと。
シェルスクリプトでの自動化処理開発など。
ITサービスマネジメント
ITサービスを運用する上で、問い合わせ対応などの業務も欠かせない。
ITサービスマネジメントのベストプラクティス集であるITILには以下のような業務が載っている。
サービスサポート：日常的なサービス運用
・サービスデスク：利用者からの問い合わせを受け付ける
・インシデント管理：障害などのサービスを阻害する事象（インシデント）に対応し、サービス状況を回復する
・問題管理：インシデントが発生した根本的な原因を解決し、未然に防ぐ
・サービス資産管理および構成権利：所有するIT資産を正確に把握し、管理する
・リリース管理および展開管理：実際に変更を実施し、ユーザー教育などを行う
障害対応の一般的な手順は以下の通り。
受け付けと記録→分類・判別→（可能なら）応急処置→優先度決定→原因究明・解決
障害対応の流れを書くとこんな感じなのだけど、これに必要なスキルは地味だが重要。
・事象を正確に記録すること
・ステークホルダーに事象を共有すること
・事象の優先度を決定すること
・原因を究明すること
・対策（するかどうかを含めて検討し）をすること
サービスデリバリ：中・長期的なサービス業務
・サービスレベル管理：サービス品質（水準）について合意・管理する
→利用者と提供者がサービス水準について交わす合意のことをSLAと呼ぶ
・ITサービス財務管理：会計処理や課金処理などを実施する
・キャパシティ管理：負荷に適切に対応できるか監視し、必要ならば修正する
・ITサービス継続性管理：緊急事態における復旧処置などを検討・実施する
・可用性管理：信頼性や保守性を高める
この本で取り上げられていたのは要件定義〜基本設計のフェーズ。
