運用設計のアウトプット
運用設計のアウトプットについて、今日は書きたいと思います。これもPJによって様々です。私が経験したPJで共通的に作っているのは以下の通りです。
- 運用設計書（監視対象やログ管理、バックアップ方式など）
- 運用体制図
- 運用フロー図
- 作業手順書／作業チェックリスト
- 運用スケジュール（定期作業イベントの管理）
- 管理台帳（構成管理、インシデント管理等）
運用を続けていると障害が発生し、それを蓄積する仕組みを持つことが重要です。運用するメンバーも変わりますし、お客様も異動でいなくなることもあります。そのため、障害発生時、それが過去発生事象なのかどうなのかというのがわかると、工数の削減もでき大事になります。過去発生事象であれば、同様に対応すればいいでしょうし、何回も発生するのであれば、システムとして根本的に対応する必要があります。
少しだけ補足すると、運用で対処できるような不具合に関してはお客様はなかなかお金を出してまで対応を考えてくれないのが一般的ではないでしょうか。同様な機能を改修する際に一緒に直したりすることが多いように経験的に思います。
運用して発生する問題を体系化する仕組みを作るというのが、運用設計段階でできていると、運用後は運用担当者はすごく楽になります。
発生した問題を運用項目として落とし込める現場は、なかなかないのでそのような現場を作っていきたいですね。
運用設計やってないじゃん！
SEをやっていると納期を優先した結果、なんとかシステムは動いたが運用開始後トラブルが多発なんて経験ありませんでしょうか。そしてそんな時は大体運用設計がされておらず、トラブルにどのように対応すればいいのか不明とか目も当てられない状況。
過去、以下のようなシステムを目にしてぼうぜんとしたことがあります。
- 設計書が残されていない。もしくは、更新されていない。
- コーディングが雑。
- 外接システムとのデータ連携が不明
- バッチ処理が複雑
- ログが取得できない
こんな具合にその後の運用保守フェーズを全く考慮されていないシステムは、その後面倒を見る人の時間を奪っていきます。そもそも、将来的な変更を想定しないということがよくあります。今の世の中、作りっぱなしでその後運用するシステムなんてありません。必ず何かしらの改修がおこわなれます。その時に必要な設計ドキュメントが残っていない、ソースコードがぐちゃぐちゃで可読性が低いというのは、最悪です。なので、このような状態を作らないように、運用後の運用設計を実施して運用担当者を楽にしてあげましょう。
監視設計ってなーに
監視設計って運用をする上で、すごく大切です。監視ができないと、エンドユーザから突然システムが動いていないとか連絡がきて対応が後手になってしまいます。
システムの監視は「システムのサービスに対する監視」と「インフラの監視」の2種類に分けることができます。それぞれの監視種別の役割の違いを理解することで、システムに対し適切な監視項目を選定することができます。
サービスの監視とは利用者が直接アクセスして利用するサービスの監視になります。
Webサイトにアクセスし正しく表示されるか、入力した値に対し想定通り応答があるかなど利用者向けのサービスに対しての監視を指します。
インフラの監視は、ハードウェア機器やOS、プロセスなどシステムを構成する要素の監視を指します。
サービスの監視は利用者に提供しているサービスを直接監視しているため、異常を検知した際の緊急度は高くなります。すぐに対応が必要になります。
インフラの監視は構成要素の監視であるため、異常を検知してもサービス影響がない場合があります。
例えば、冗長化されている機器の片系が停止してももう片系でサービスが提供し続けていればサービスヘの影響はありません。
または、急なcpuの高騰が発生してもしばらく経過して落ち着けば問題ないです。
また、構成要素の監視であるため監視項目が多くなります。
障害の予兆を検知できないとサービスに影響が出かねないため、細やかな監視項目の設定が必要となります。
システム開発では運用設計って考慮不足がち
私は15年近くSE（システムエンジニア）をしています。大規模のシステム開発プロジェクトから小規模のシステム開発プロジェクトまで、様々な開発PJに携わりました。中国やベトナムなどオフショアのメンバーとも仕事を一緒にした経験もあります。
そのため、ウォータフォール開発に関しては、メリットもデメリットも理解しているつもりです。
システムを開発し、お客様に納入するためまでには、色んな役割の人が携わります。たとえば、アプリケーションが動く基盤を作るインフラエンジニアやネットワークを構築するネットワークエンジニア、アプリケーションを作成するアプリケーションエンジニア、全体を管理するプロジェクトマネージャなど様々な人が関わり合ってシステムが出来上がっていきます。システムは構築してお客様に納入して終わりではありません。
その後何年間もお客様はシステムを利用し続けます。むしろ納入してからの方が、長い期間システムを利用することになります。システムを長期間運用していると必ず障害が発生します。アプリケーションの不具合が起因で発生するシステム障害、ハードウェアの故障起因で発生するシステム障害など多岐に渡ります。障害の原因究明にも時間がかかるケースもあります。
しかし、どのような障害が発生するのか等、サービスイン後を考えてシステム開発が進むことは稀ではないでしょうか。サービスイン後、どのようにシステムを運用していくのかあまり議論されず、サービスインを迎えるプロジェクトがほとんどだと思います。しかも、システム開発は納期があります。
ほとんどの開発プロジェクトは予定より遅れます。そのためサービスインギリギリでなんとか開発を終え、納期を優先した結果、なんとかシステムは動いたが運用開始後トラブルが多発なんて経験ありませんでしょうか。
今回、このブログを通じて運用開始後に運用者が困らないように、システム開発中に考えておくべき運用のことを記載したいと思います。一般的には、運用設計という言葉が当てはまると思う。
運用設計で考慮するべき項目は決まったものはなく、現場、システムの規模や組織の規模によってさまざまである。それは、システム導入後の運用業務が現場、システムの規模、組織の規模で変わるからである。
監視設計、ログ設計、バックアップ設計など検討するべき項目としてわかりやすい部分と、実際に運用を開始しないとわからない部分がある。今回私の経験を元に、できる限り共通的に考えなければならないことを記載していくこととします。
