IT保守運用サービスを提供する際のポイント
ごあいさつ
DWSのみやたんでございます。
組織内でプロダクト開発やオファリングに関連する業務が少しずつ増えてきているのがきっかけで、このたびIT保守運用サービスについて触れる機会がありました。
過去私が担っていた経験をまとめて、どうすればお客様によいIT保守運用サービスを提供できるかまとめます。
本記事の概要
IT保守運用サービスでよく対象となる「インシデント対応」に関する落とし穴をまとめます。
ここで、「インシデント対応」とは、システム異常やセキュリティ事故等が発生した場合に、影響を最小限に抑えてシステムを使える状態に戻すことを指します。
なぜこの題材を取り上げたのか
サービスを検討する上で、お客様のニーズを忘れてはいけないと思います。これまで私の過去経験で数百のお客様にIT保守運用サービスを提供しており、その経験もふまえてサービス立ち上げや改善時に役立てられるようにしたいと考えています。
「インシデント対応」の落とし穴
これまで経験した中で「インシデント対応」における失敗事例や注意事項をまとめます。
一番重要なことはお客様と保守運用に関する取り決めの認識をあわせ、合意しながら対応することと考えます。
以下は一例となるため、すべてのお客様に当てはまらない場合もあり、お客様ごとにご希望を理解することが必要です。
-
お客様への連絡は素早く実施する
IT保守運用サービスを検討させるお客様(契約者様)の先には大抵システムを実際に利用するエンドユーザー(利用者様)がおります。
お客様としても、保守運用すべきシステムに異常が発生して利用制限もしくはサービス提供不可の状態になった場合は一刻も早く認知して、利用者様に対して、お客様側でも必要な対応を迅速に実施する必要があります。
そのため、影響が不確定の段階や誤検知の可能性であっても躊躇なく素早く連携する方が好ましいことが多いと感じます。 -
技術担当者が作業を抱え込んでしまう
「インシデント対応」発生時に、技術担当者は原因不明の事象に対して、一刻も早く復旧するために冷や汗をかいて一生懸命対応しているケースがほとんどです。
その余裕がない中で体制や取り決めの仕方が悪いと負荷が集中してしまう可能性があります。
「インシデント対応」中の必要な作業を書き出してみます。- お客様との状況連携を実施
- システム上で発生しているトラブルの状況把握、影響調査、原因分析、対策検討
- 技術担当者が所属する会社内への共有、エスカレーション
- システムを動作させる仕組みをサポートするベンダーや窓口との調整
- 連携先システムへの通知、調整
これらの対応を一部の技術者のみで実施すると、復旧までに時間がかかり、作業および連携の品質が低下することが容易に想像できます。
しっかりルールを整理して、適切な体制や役割分担のもと実施していくことが必要です。
-
復旧優先か原因調査優先か
発生する「インシデント対応」にもよりますが、システム動作に影響が出て特にサービス提供が著しく制限されている場合は一刻も早い復旧が望まれます。
その際に、原因よりも復旧を優先させるのか、原因調査を優先させるのかも状況に合わせてお客様と適切にやり取りするのが望ましいです。
システムを構成する技術は年々進歩しており、障害時の保全やバックアップからの復旧などは非常に早く正確にできるようになっていますが、まだまだ旧来の仕組みが残っているシステムも多く存在します。
最新技術を使ったシステムではない場合、後で原因調査する際には、インシデント再現性や記録(ログ)確保、あるいは発生したインシデント状態の環境を保全する方法をあらかじめ検討して、後で情報不足で原因調査不可とならないようにしておく必要があります。 -
報告書記載内容
「インシデント対応」後には状況をまとめてお客様へ報告します。
その際に、お客様が必要と考える情報を盛り込むことも大事なポイントだと考えます。
お客様はその情報をもとにお客様内の組織や利用者様にも報告が必要だからです。- サービス制限が発生していた時間帯と機能一覧はなにか。
- 利用者様からはどのような状態でシステムが表示されていたか。
- どのくらいの利用者様が接続していたか。
- 原因や対策が暫定となる場合、いつまでに最終的な対応ができるか。
- 作業経緯プロセスに問題はなかったか。 など
まとめ
「インシデント対応」は非常に難しくまた誰にとってもプレッシャーのかかる嫌な存在ではありますが、適切に対処することで負担を軽減し、より高品質なサービスが提供できる考えています。
最後までご覧いただきありがとうございました。
