IT運用保守の世界

柚人

久しぶりに書くnoteです。
普段自分は某外資で日系グローバル企業相手に、海外のオフショアエンジニアと日本人ユーザーの間に入ってIT運用保守サービスのサービスデスクでインシンデントマネージャーをやってます。
かれこれ入社して1カ月経過後にインシデンントマネージャーに抜擢されてから1年半余りが経とうとしています。

この記事を書こうと思ったきっかけは以下のMicrosoft吉松さんの記事。

ここでいわれている障害対策の専門チーム、というのは自分のプロジェクトにおいてはMIM（Major Incident Management）というチームに分類されています。
MIMに至るまで、サポートエンジニアって普段どんなことしてんの？っていうのを知ってもらうとともに、「安い」「きつい」「暗い」といったイメージを持たれてる方の意識払拭につながればな、と思って書いています。

IT運用保守って？

さて、まず初めにITにおける運用保守をざっくりいうと
・計画外で止まらせない
・様々な関連ケースを切り分け速やかに解決する
・要求された作業を規定時間内に終わらせる
・変更を記録する
・定期的な更新を計画し、実行する
・ナレッジを蓄積し、必要なものをユーザーに告知する
この5点です。

自分のやっているプロジェクトはITインフラなので、アプリケーション以外すべてが責任範囲です。
資産/ライセンス管理、ネットワーク、サーバー、PC、セキュリティ、How to、申請ワークフロー、アカウント。
一人情シスの方だと全部触りますが、大規模なプロジェクトになると、これらを動かすのに100~200名近くの関係者が1リージョン（国）にいます。
クラウドの世界でいうPaaS（Platform as a Services）の運用版に近いですね。
ここは契約によって変わってきます。

計画外で止まらせない

サーバー、ネットワークが主ですが、システムや業務は基本的にメンテ時間以外稼働させ続けなければいけません。
そのため、止めないことも大事ですが、止まらせないために意図的に止めてメンテを定期的に行うことが大事です。
もちろん、計画外で止まってしまった場合は、そのサービスの重要度において復旧目安時間内に解決することが求められます。
サービスの重要度は「ユーザー数」や「利用頻度」「機能」によって決められます。

様々な関連ケースを切り分け速やかに解決する

ITILではIncident Management（障害管理）の部類に属します。
インシデント、という言葉と聞くと、例えばデータが漏洩した、などの「セキュリティインシデント」を思い浮かべがちですが、「業務ができない状態」をまるっとインシデント、と呼ぶケースもあります。

IT技術者間でもよくあるインフラ側とアプリ側で話が通じない、押し付け合いが起きる、ということがありますが、自分のいるプロジェクトのように一般ユーザー（顧客企業の従業員）からの問い合わせも受けるケースでは、サービスデスクが人数が多く、そして求められる難易度が高い部分でもあります。

システムがつながらない、という一言で問い合わせを受けたときに、システムが止まってるのか、問合せ者だけが使えないのか、はたまた推測される原因は何なのか、それらに柔軟に対応しようと思うと、落ち着きと広範な技術知識が求められるので、一次受けの自分のチームでは自分を含めメンバーに対してのナレッジのインプットが非常に多いです。
その中で、やはり優劣がつくのは「技術に興味があり、自ら調べる力があるか」にかかってきます。
そして、それらから概要を理解し、一般ユーザーに分かるように伝える一種の「語学力」が運用保守エンジニア、特にサービスデスクには必要となります。

もちろん、それらの中で明確になっていないプロセスなどが出てきたら、関連部署と連携を取り、プロセス構築していくことで普段の対応速度や、新人が入ってきた際などの対応の質の向上にもつながります。

要求された作業を規定時間内に終わらせる

ITILではService Request Management（要求管理）に属します
ここは主に運用面の中でも、例えばサーバー構築依頼であったり、ネットワークでいう固定IP割り当てであったり、アカウント登録や削除であったり、そういった決められた手順で決められたとおりに行うものをいいます。
これらの単純作業も運用保守に含まれますが、運用保守を行う時点で必要なのは「手順」「プロセス」です。
そして、これらによって標準作業時間が決められ、何時間以内・何日以内にやらなくてはならない、といったSLA（Service Level Agreements）が定められます。

変更を記録する

ITILではChange Management（変更管理）と言われます。
設定変更の計画、およびそのプラン、実行、実施時のリカバリプランなどがここでされますが、冒頭で記載した吉松さんのようなMIMチーム管理下に置かれた障害発生起因の設定変更などは「緊急変更」とされ、決裁者の承認次第で実施されます。
通常の変更は、既定日に承認を行い、承認されたものだけその後に実施されます。
ここにおいてサービスデスクは直接絡みませんが、障害発生時にはユーザーの苦情を受け付ける、先日の携帯キャリアの大規模障害でいう「ショップの店員」の立場になります。

定期的な更新を計画し、実行する

ITILではChange ManagementでもありますがProblem Management（問題管理）にも属します。
問題管理は、例えばOSのサポート期限切れが近かったり、障害ではないけれど不具合を抱えていたり、と即座に解決できないものを貯めておく、目途が立ったら解決に向けて行動することを目的としています。
変更管理は実際に手を動かすタイミングの話で、問題管理は解決できる問題かどうか、解決できないなら暫定でどうやって、いつまでに恒久対策を行うか、といった部分を管理するが主になります。

ナレッジを蓄積し、必要なものをユーザーに告知する

ITILではKnowledge Management（ナレッジ管理）と言われます。
ナレッジにはいくつかの属性が存在します。
1.手順を示したHow to系ナレッジ
2.仕組みを説明する技術系ナレッジ
3.ビジネス背景やポリシーを記載したアナウンス系ナレッジ
4.ユーザーには見せられない設定・フロー系ナレッジ
これらを分類、うまくネスト（ナレッジ同士を階層化したり紐づけたり）することで、問合せ自体を減らせることができます。
このナレッジが多く、問合せ件数が少ないほど成熟した組織と言えます。
なぜなら、プロセスが固まっていて、それらが常に周知できていて、ユーザーの理解度が高い組織と言えるためです。

逆に作る余裕がない、という場合は早めに増員して専任者を当たらせたほうが良いのですが
・読み手の層や読解力を意識して、わかりやすく書ける
・同じ内容をいたるところに乗せない
・常に最新の情報に更新できる
これらを意識して出来る人でない人が作ると、効果を発揮することができません。
中には技術知識が豊富でないと書けないものもあるので、そのあたりでも各分野のエンジニアのうち、ユーザーにわかる言葉で書ける、ということは運用保守において重要な要素と言えます。

運用保守の世界で求められる人物像

分野にもよりますが、ただのオペレータは溢れていますし、面接で落とす・落とされる場合もあります。
総じて落とされる人は以下の要素のいずれかを満たせていません。
・エンジニアとして基礎知識がある（用語が理解できる）
・トラブルシューティングのすべを知っている
・ビジネス面で適切な応対ができる（言葉遣い、企業としての視野）
運用保守の世界でも、チームのTechnical LeadやManagerクラスなら外資では800～1000前後は固いです、安い方かもしれません。
ただし、そのレベルからは必ず英語での会話が求められます。

それぞれの技術分野の専門家とは違い、MIMやIM、CF（Cross Function）などはプロセス・横断的処理の専門家で、非常に幅広い人的ネットワークを持ちつつ、障害発生時などはリーダーシップを発揮し各チームへの呼びかけを行うなど、司令塔としての役割を果たします。
その際に、どういう問題が起きているか、だれを動かさなくてはいけないか、を瞬時に判断する必要があるため、アンテナの広さや論理的思考力が大事になってきます。
また、この人たちが主に事業影響の決定者に対して諸々報告・提案する調整役になるので、ビジネス面でも欠かせない立場になります。

おまけFAQ

障害ってどんな頻度で発生するの？何から障害？

重要度、という話を上げましたが、実際には優先度という表現をされ重要度は優先度を決める一つの要素です。
障害、としてMIMが動き始めるのは、下記のランク付けでいう、高または最高の場合に限定されることがほとんどです。

最高：全員が使えない状態、業務が止まっている状態
高：一部ユーザーが使えない状態、業務が著しく低下してしまっている状態
中：特定のユーザーが使えない状態、回避策で業務はできる状態
低：個人が使えない状態、業務にほとんど支障がない状態

発生頻度は正直たぶん環境によってバラバラだと思います。
余裕をもってIT運用ができている企業は、それだけ会社がIT運用に理解があり、そもそも問題を起こさせない文化が出来ています。
自分の環境では月1ペースどころか毎週起きていた時期があったので、結構メンバーも含めてかなり鍛えられました。

サポートエンジニアではどんな分野が手薄？

正直全般的に手薄だと思っています。
特に今の段階ではセキュリティ系が非常に手薄です。
いわゆるウィルス対策ソフトや不正アクセス監視などの特定製品のスペシャリストは多いのですが、IoT機器やスマートデバイス、認証などの多様化によりネットワークの重要性と物理面のセキュリティをどれだけ維持しつつ、踏み台にされないセキュリティ環境の構築のために対応できる人は多くありません。

コードは書いたりあるの？

かなりの確率で「ありません」。
多分運用保守でもアプリ系ならまだしもインフラ系なら書くのは関数やコマンドでしょう。
たまにバッチファイルの中身やアプリのxmlを見たりすることがありますが、そこまで出来るのはもともとそっちの分野で経験がある人です。
ただ、一つ言えるのは「プログラミング言語」を使わないだけで、思考方法と書く文書ではコードチックに物事を書けることがかなり大切と思っています。
例：
　現在こういう問題が起きている
　　AとBとCの点を確認する
　　　AとBが=でCの際にはこの条件が当てはまる
　　　　その場合aの処理をこのプロセスで行う
　　　AとCが=ならbの処理になる
といった感じに構造化して書けることは非常に重要です。


この記事が気に入ったらサポートをしてみませんか？