社内SEの腕の見せどころ、運用設計って何するの? | 情シスあるある

先日の「社内SEに最も求められる折衝スキル。社内折衝って具体的に何するの?」で触れた、運用設計について詳しく紹介します。

運用設計って何?

ITエンジニアで運用設計に携わったことがある人はそんなに多くないと思います。

私も前職では1回しかやったことないですし、
その1回もお客さんの要求に合う成果物は出せませんでした。

簡単に運用設計について解説します。

何を決めるの?

一般的に運用設計は下記を設計します。

  1. 業務内容
  2. 管理項目
  3. 運用体制
  4. 運用スケジュール
  5. 監視設計
  6. データ管理
  7. バックアップ設計
  8. 障害対応

参考:運用設計@Qiita ←シンプルだけど判りやすい。

どこが大事?

上記すべてを社内SEがやるわけではなく、依頼すればITベンダがやってくれます。

特に社内SEにスキルが求められるのは4〜6です。

ベンダにすべて任せられない理由は下記の通りです。

  1. ユーザ部門の要求をそのまま飲むと情シス担当者が最も苦しむ(ベンダは苦しくない)
  2. 他システムとの連携は情シス担当者が最も詳しい(ベンダは詳しくない)
  3. システム障害に対する影響は情シス担当者が最もイメージできる(ベンダは判断できない)

それぞれの項目について見ていきます。

CheckIT

運用スケジュール設計

最初に4の運用スケジュール設計について解説します。

何を決めるの?

運用スケジュール設計では、ざっくり下記をいつ誰がやるかということを決めます。

  1. バッチ処理
  2. マスタメンテナンス
  3. アップデート(パッチ当て)
  4. ログ確認(処理の正常完了や異常検知)

書いていながら運用って地味だなぁ〜って改めて思いますが、誰かがやらないといけない仕事です。

どこが大事?

社内SEはどういった視点でこの設計に携わっていけばよいかというと、

バッチ処理やマスタメンテなど、細かく正確にやるに越したことが無いタスクを、優先度をつけていかに減らしているか

になります。

ユーザ部門が味方になってくれない

大体の場合、ユーザ部門は上記の対応の経験もないですし、自分に負荷がかからないタスクなので、

ユーザマスタのメンテは日次でやるべきだ!とか、土日もバッチ処理を手動で回したい!

とかいきなり言ってきます。

これをシステム屋の観点で説得して、そこまでやる意味ありますか?と問いかけることで、
運用フェーズの手運用を減らせるのです。

一旦運用が始まったものはなかなか変更できないのでこのフェーズはかなり重要です。

設計する女性

監視設計

システム監視っていう概念自体を知らないエンジニアの方が多いと思いますので、まずは概念から説明します。

システム監視って何?

簡単に言うとシステムが正常に動いているかどうかを調べて(検知)、それをシステム管理者に伝える(通知)することです。

監視にもいろいろありますが、下記図がわかりやすいので借用します。

Image by ThinkIT 「正しいシステム運用のための監視要件定義」

ユーザにサービスを安定的に提供するには、
ユーザから見えるサービス監視だけではなく、
サービス停止を未然に防ぐ、ハードウェア監視やリソース監視が必要となります。

監視の目的は、下記の2点になります。

  1. システム管理者がエンドユーザの誰よりも先に障害に気がつくこと
  2. サービス障害を未然に回避すること

どこが大事?

監視は上記図の通り、かなりの情報が取れます。

ITベンダに設計を依頼すると、
監視項目の一覧とそれに対するアクション(電話 or メール or 静観)の一覧を作ってきて、
アクションはどうしますか?って聞きます。

ITベンダに案は作れますが、最終的には絶対社内SEが決めないといけません。
ユーザ側は「多くの情報をキャッチして早く検知できるに越したことは無いよね」くらいしか認識できません。

適切な通知量を見誤ると本末転倒

ここで。とりあえず多くの情報をキャッチするという風にすると、

定常運用でも大量の通知メールが送付されてきて、そのうち誰も見なくなります。

つまり、小トラブルが多すぎるとトラブルに慣れて、大トラブルを見逃すわけです。

優先度付けと適量の見極め

できるベンダ(担当者にも依るが)は、こういう提案をしてくれます。

  1. 会議中でも深夜でも最優先で知らせて欲しい障害→電話
  2. 翌営業日の朝に気がついて対処すれば良い障害→メール
  3. 月に1度のレベルで気がつけば良い障害(予知情報)→ベンダに月次レポート出させる

1と2は簡単に層別できますが、2と3の層別は難しいです。

経験上、迷ったら3にして、それが要因で障害が置きてしまったら2にする割り切りが必要

ですね。だって2が多くなって見なくなったら本末転倒ですから。

データ管理

データ管理もピンと来ない人が多いと思いますが、
簡単に言うとマスタメンテナンスとトランザクションデータ(またはファイル)のゴミ掃除です。

どこが大事?

マスタメンテナンスもユーザがやらない範囲は味方してくれません。

できるだけ最新の情報をシステムに反映して欲しいくらい、くらいしか興味がないです。

長くなるので詳細は別記事にまとめました。

関連記事:社内SEのライフワークと化すマスタメンテナンスの実状から目を逸らすな!

おわりに

長くなってきたのでこの辺で終わりにしますが、

書いてて嫌になるくらい地味です。
でもしっかり設計しないと地味な作業をやり続けるのは自分なので、後悔しないためにもきっちりやらないとダメですね。運用設計。

以上です。