サーバエンジニアの運用保守ってなにやってるの？

はじめに

サーバエンジニアが携わる作業工程としては、ざっくり以下のように分けられます。

• 要件定義
• 設計
• 構築
• テスト
• 移行
• 運用保守
• 監視

今回は上記の中でも「運用保守」において、「実際に何をしているの？」を私の経験から紹介します。

専門的な用語が分からないところもあるかもしれませんが、「結構学べることが多いんだな。」、「上流工程への挑戦にもつながるんだな。」というのを感じてもらえると嬉しいです。

運用保守とは

運用保守とは、簡単に言うと担当するシステムの提供するサービス、業務を継続して行えるよう安定稼働させる。また、障害時の対応を行うことです。

いかに効率よく、より良く、継続的に(または早急に復旧させて)サービスを提供できるか、が味噌です。

もう少し具体的な定義を知りたい方は以下を確認してみてください。

政府CIOポータル
デジタル・ガバメント推進標準ガイドライン実践ガイドブック
（第３編第９章 運用及び保守）
https://cio.go.jp/sites/default/files/uploads/documents/jissen-guide_9.pdf

実際に何をしているの？

継続的に安定稼働させる。と言っても何だかよくわからないと思うので、もう少し具体的な業務の内容に触れたいと思います。

業務の種類

まず、業務には定常業務と非定常業務があります。
定常業務は日次、週次、月次、四半期、半期、年次など決まったサイクルで繰り返し行われる決まった業務です。
非定常業務は上記以外の業務です。(トラブル対応など)

次にどういった定常業務があるか、どういった非定常業務が発生するかは顧客やシステム、立場によって違います。

例として私の経験したActive Directory(以下AD)サーバの業務について紹介します。

Active Directoryはとても超簡単に言うと、Windows Serverに搭載されている役割の一つで、組織のユーザーやコンピュータなどを一元管理するものです。

定常業務

定常業務としては以下のような作業を行っていました。

作業項目	作業内容	サイクル	備考
ADオブジェクト登録/削除	ADユーザ、コンピュータ、グループなどの登録削除 ・受付 ・作業準備(手順や作業日時調整) ・作業	日次
DNSレコード登録/削除	DNSレコード(A、CNAMEなど)の登録削除 ・受付 ・作業準備(手順や作業日時調整) ・作業	日次
問い合わせ対応	システムゲストからの問い合わせ対応 ・受付 ・調査 ・回答	日次
システム状態バックアップ	ADのDB領域バックアップ	日次	JP1ジョブで自動化
イベントログバックアップ	イベントログのアーカイブおよび長期保存領域への転送(監査対応)	日次	JP1ジョブで自動化
進捗管理	業務タスクの進捗状況管理	日次
顧客定例	業務タスク、課題、トラブルなどの進捗報告	日次
システムバックアップ	サーバ全体のバックアップ	週次	JP1ジョブで自動化
パッチ適用	毎月公開される最新のパッチ適用	月次	JP1ジョブで自動化
パフォーマンス状況確認	CPU、メモリ、ディスク他、サーバのパフォーマンス状態を確認 ・パフォーマンスデータ確認 ・報告資料作成 ・顧客報告	月次
活動報告	チームにおける当月または前月の活動を顧客に報告、今後の方針すり合わせ、営業活動など	月次
ID棚卸	不必要なIDが存在しないか、不適切な権限が付与されたIDがないかの確認	半期
脆弱性診断対応	システムのセキュリティのリスクチェック	半期
DR訓練	DR計画に沿って問題なくDR切り替えが行えるかの訓練	半期
運用保守業務の棚卸	次半期に行う運用保守業務の見直し(コストの観点を含む)	半期

非定常業務

非定常業務としては以下のような作業を行っていました。

作業項目	作業内容	サイクル	備考
ADオブジェクト登録/削除	定常業務以外で普段あまり変更が行われないオブジェクト(OU、GPO、信頼関係など)の登録削除	都度
DNSゾーン登録/削除	定常業務以外で普段あまり変更が行われないゾーン(前方参照、条件付きフォワーダなど)の登録削除	都度
SOX監査対応	システムのコンプライアンスチェック ・SOX監査に対するデータ提出 ・評価内容確認 ・指摘対応方針策定 ・指摘対応	都度
緊急パッチ適用	システムに重大な脆弱性が発見された時に行う緊急のパッチ適用作業	都度
サポート期限管理	OSやSWなどのサポート期限の管理	都度
トラブル対応	システムに発生したトラブルの対応	都度
課題対応	業務やシステム構成における課題の対応	都度

定常業務/非定常業務 以外にも

定常業務、非定常業務について紹介しましたが、運用保守業務の債務を履行する範囲の話です。
運用保守では複数人のチーム体制で参画することが多く、長期的に参画することが多いです。
また、EOLに伴うシステムの更改案件やゲストシステムの関係システムとしての対応案件などに繋がることが多いです。
そうした中でビジネスを継続、拡大するために行うことがあります。
(上流工程に入るチャンス！)

• 改善対応
  通常業務の中で対応できる範囲の改善であれば、どんどん行うべきです。ただし、対応内容によっては相応のシステム変更による影響、作業工数を必要とすることがあります。
  それによって通常業務に支障をきたすと元も子もないです。
  そういった改善対応については運用保守とは別枠で案件化を提案します。

• EOLに伴うシステムの更改案件
  担当のシステムが提供するサービスが顧客として必要である限り、OSやSWのEOLに伴って更改対応が必要になります。
  更改対応に際して、現行のシステム構成、運用などを一番理解しているのは運用保守を行っているエンジニアです。更改案件を任せてもらえるように行動することが重要です。
  現行システムの課題や更改後に求められる要件を前もって顧客と会話し、案件化を提案します。

• 顧客の企業方針をキャッチ
  前述したとおり、運用保守は長期的に参画することが多いです。そのため、セキュリティ対応やDX化など今後立ち上がるであろう案件の想定しやすくなります。そういった場面で顧客の方針や要望をヒアリングし、対応案などを提案します。

運用保守に携わるメリット

ここまでサーバエンジニアの運用保守でどういった業務を行っているか紹介してきましたが、やはり要件定義や設計などの上流工程に比べると少し地味。。
ただし、エンジニアとして学べることは多々あります。ここからは運用保守に携わるメリットをいくつか紹介します。

1. 担当システムに用いられる技術を深く知れる
顧客は安定稼働の観点からエンジニアに長期的に参画を望むことが多いです。そのため、定常業務を通して基礎を、非定常業務を通してより深く技術を身に着けることができます。

2. 広い視野が身につく
完全に新規構築のシステムであれば、構築やテストの段階でトラブルが発生しても顧客業務に影響はないです。ただし、運用保守ではそうはいきません。すでに顧客業務としてサービスを提供しています。設定変更を行う際は事前に、
トラブル対応では早急に作業の正確な影響範囲を把握する必要があります。
こういったシーンを数多く経験することで、新規構築案件ではなかなか鍛えられない判断力、状況の把握能力が身に付きます。

3. 案外いろいろな技術が学べる
前述のADサーバでお話すると、まず Windows OS、AD、DNSの知識は必須になります。ただし、その知識だけでは業務を遂行していくことができません。サーバの設定作業であればDOSコマンド、Powershellのコマンドレッドを使う機会は絶対出てきます。
また作業の自動化を行うためにスクリプトの作成、JP1を使用したジョブの作成などを行います。
さらに、サーバ以外の領域(ネットワークやストレージなど)でトラブルが発生することもあります。そうした場合は障害ポイントの切り分けのためにある程度サーバ以外の領域の知識が必要になります。
このように、1つのシステムでもいろいろな技術を学ぶことができます。

4.上流工程にステップアップしやすい
「上流工程は花形だ！」と言っていきなり飛び込んでもうまくいきません。
要件定義では現状の業務、システム導入後の理想の運用イメージなどを確認する必要があります。設計では機能的な設計だけでなく、導入後の運用設計も行う必要があります。基礎的な技術の知識に加えて、運用をイメージできるかは大切になります。
運用保守に参画することで基礎的な技術を得て、実際に経験したうえで上流工程にステップアップするのが理想的だと思います。
また、「定常業務/非定常業務 以外にも」でも記載したとおり、案外上流工程に入るチャンスはあるので狙ってみてください。

最後に

今回はサーバエンジニアの観点から「運用保守」って「実際に何をしているの？」について紹介しました。
あくまで私の経験に基づいた話なので、実際に運用保守に参画した際の参考にしつつ、それぞれの現場での魅力を見出してみてください！