【情シス】システムの導入から運用までの一連の流れを知ろう

この記事は約9分で読めます。

システムの導入〜運用の一連の流れを知る

コロナウイルスの感染拡大の影響で、ビジネスチャットやTV会議の需要が急激に高まっています。

これに伴い、勤め先でも導入したシステムがいくつかありました。

情シス部門で仕事をするにあたり、最初はもともと存在しているシステムの保守や運用業務から任されることが多いです。

そして、少しずつ案件担当者としての仕事を経験していくことになりますが、現場は忙しくて教育面まで手が回らず、何もわからないまま案件の担当になる可能性もあります。

経験が浅いと、案件の担当者となって進めていくことができず、担当者が指示した作業をこなすだけの作業者となりかねません。

顧客や社内の利用者がやりたいことに対して、システムを利用して実現するためには、ただの作業者であるだけでは不十分です。

システムを導入から運用までの一連のフローを知っておくべきだと考えています。

この記事では、システムの導入から運用までの一連の流れをまとめています。

参考書籍

今回はこちらの本を参考にさせて頂いています。

こちらの本の重要と思われる部分を箇条書きにしてまとめていますが、

詳細やなぜそうなるのか?という重要な部分はまとめるにあたり削られています。

実際に読んでみることでより理解が深まるので、ぜひ手に取って読んでみましょう。

ちなみに、この本はKindle Unlimitedの対象です(2020年8月現在)

わざわざこの記事を読んで勉強しようとしているあなたは読書の習慣がすでにあると思われます。

少なくとも本を読むことは嫌いではないでしょう。

そのため、単品で購入するよりも先にKindle Unlimitedに登録してからダウンロードした方が、今後の書籍代の総額が安くなるはずです。

1.運用と運用設計

  • ITシステム運用とは、ITシステムをうまく働かせて使うこと
  • 利用者に安定してサービスを提供するために運用設計をする必要がある
  • 運用開始はサービスイン・カットオーバーと呼ばれる
  • 運用を実施する担当者は3種類(運用担当者、監視オペレータ、保守担当者)
  • 運用担当者:問い合わせ対応、定型作業、非定型作業、障害対応/報告を行う
  • 監視オペレータ:不具合発生の監視、報告、不正アクセスなどセキュリティ監視も兼ねる
  • 保守担当者:障害発生時の部品交換やメンテナンスを行う
  • システムは複雑化しているため、運用設計書を使って担当者に必要な情報をまとめる必要がある
  • 必要な情報をまとめることを運用設計といい、システムの安定稼働や障害発生時の早期対応に資する
  • プロジェクトはシステム基本計画、提案対応、要件定義、基本設計、詳細設計、テスト、移行の順で進む
  • 各フェーズで成果物を作成する:要件定義書、基本設計書、運用設計書、詳細設計書、テスト仕様書、移行計画書
  • 要件定義書:利用者が何をしたいか、そのための機能面、性能、信頼性、拡張性、運用性、セキュリティなど非機能面の要件を記載する
  • 基本設計書:機器構成、画面・帳票などの操作、入出力データハード-ソフトの連携など要件定義書にの要件をどのように実現するかを記載する
  • 運用設計書:システム運用に必要な項目と情報を記載する。手順書、台帳、関係者など運用開始後の必要なドキュメントになる
  • 詳細設計書:パラメータシートやプログラム設計書などの設定値などを記載
  • テスト仕様書:正常性、性能などの確認項目を記載
  • 移行計画書:本番環境へ移行させるための必要な情報を記載、切り戻し、移行期間中の制約を含む

2.要件定義フェーズ

  • 導入したいシステムの概要がまとまれば、システムに対する要件をまとめる要件定義を行う
  • 本来顧客が行うが、詳しくない場合はSIerがついて行うことも多い
  • 実装する機能、達成する性能を検討する
  • 導入に必要な費用を計算する資料にもなり、経理・経営層も読む
  • 費用、スケジュールなどを見て実現方法を複数検討する
  • まずは社内事例、ネットでの検索、メーカー問い合わせにより情報を集める
  • 要件の変更は起こりやすいため、基本設計時に可能な限り検討しておき手戻りを防ぐ
  • 顧客には明確な解がないため、こちらから実現方法、解決策を提案していく
  • 現在のシステムを利用する現行踏襲でも、メリットデメリットは最低限検討しておく
  • 要件には機能要件と非機能要件がある。
  • 機能要件はシステムが満たすべき機能、非機能要件はIPAの「非機能要件グレード」により定義されることが多い
  • 非機能要件に関する考え方:可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境
  • 要件定義での検討項目:運用体制、アカウント管理方法、セキュリティ対策、自動化、バックアップ・リストア、監視、ログ管理、稼働統計
  • 移行の検討項目:運用作業の引き継ぎ方法、データ移行、ユーザーへの説明、切り替え時期と周知
  • BCP/DR:2011年の震災やコロナウイルスの感染拡大により、BCP/DRは重要になっている
  • BCP:事業継続計画、災害時の限られた資源での事業継続について定める
  • DR:災害復旧、災害時にどのような体制でデータ・機器調達を行いシステムを復旧させるかを定める
  • DRの方式:バックアップ、コールドサイト、ウォームサイト、ホットサイト
  • 保守契約を次の項目を確認する→必要なサポート態勢、目標復旧時間、機器の保守期間

3.基本設計フェーズ

  • 基本設計:要件定義書を元にシステムの具体的な仕組みを決める(外部設計、概要設計とも呼ばれる)
  • 基本設計書はどこで、何を、どのように実施するかを記載し、運用設計書にはいつ、誰が、なぜ実施するかを記載する。内容が被るため、責任の範囲を明確に決めておく
  • 運用設計書に記載する項目:共通項目、ITILプロセス項目、システム運用項目
  • 共通項目:序文、運用設計方針、運用体制、業務運用、保守運用、ライフサイクル(運用期間)、運用項目一覧
  • ITILプロセス:インシデント管理、問題管理、変更/リリース管理、構成管理、情報セキュリティ管理、SLA、可用性管理、拡張計画、サービスレポート
  • システム基盤項目:監視、ジョブ管理、バックアップ・リストア運用、ログ管理、

4.詳細設計フェーズ

  • 基本設計で決めたことを実装できるレベルに落とし込む
  • ソフトウェアチームは内部設計、プログラム設計書を作成
  • ハードウェアチームはパラメータシートを作成
  • 運用設計チームは運用フロー、手順書、台帳の作成
  • 運用フロー:業務開始のきっかけ(依頼・定時)と関係者の情報連携の方法を明確に記載
  • 運用手順書:対応者のスキルレベルに合わせて粒度を変える
  • 台帳・一覧:静的なデータは一覧、更新されるデータは台帳と呼ぶ
  • 監視設計:サービスの正常稼働、停止の予兆を確認し、障害発生時には迅速に対処できるよう準備するため、監視対象、方法、オペレータへの通知方法を決める。サービス監視とインフラ監視がある
  • サービス監視:サイトの表示、正確なレスポンスなど
  • インフラ監視:ハードウェア、リソース、プロセス、ログなど
  • 監視設計にあたり、顧客がどこまで状況を把握したいかを確認する(深夜に電話してもいいのでリアルタイムなのか、翌日にまとめて報告なのかなど)
  • 監視の運用体制、監視ツール、監視サーバの場所なども決めておく
  • バックアップ設計:取得周期、RTO、RPOなどを決める
  • バックアップはシステムバックアップとデータバックアップの2種類に分けられる
  • データリカバリ:バックアップデータの復元はリストアと呼び、リストア後に障害発生前の状態に復旧することをリカバリと呼ぶ
  • ログ設計:ログには障害調査と監査対応の役割がある
  • 複数のログを横断的に確認することもあるため、ログ管理ツールを使う方が良い
  • ログ管理ツールは、一元管理、分析・レポート、圧縮、モニタリング、原本管理・改ざん防止機能を持つ
  • 自動化設計:自動化に適した作業を洗い出し、自動化を検討する
  • 自動化には工数削減、品質向上、スピードアップ、属人化排除のメリットがある
  • 自動化の際は作業時間の計測により効果測定を行う

5.テストフェーズ

  • 設定内容の確認と、システムが正しく動作することを確認する
  • 要件通りの性能を満たさない場合は修正を行う
  • テストには仕様書が必要となり、実施手順、合否判定基準、結果、実施日、実施者、課題管理番号などの項目が必要となる。
  • テスト時には必ず証拠を残しておく
  • テストには単体テスト、結合テスト、総合テスト、運用テストなど複数の段階がある

6.運用引継ぎ

  • 運用引継ぎとは、運用担当者が手順を理解し、必要なデータにアクセスできるようにすることが目的
  • 運用引継ぎにはドキュメントの引継ぎとスキルトランスファーがある
  • ドキュメントの引継ぎでは、操作手順や顧客説明用の成果物、議事メモなど意思決定の材料も資料として担当者に引き継ぐ
  • スキルトランスファーは運用担当者が触れたことのない機器や設計思想があれば勉強会などを開いて理解してもらう。
  • 引継ぎ資料は手順書と設計書などでは参照する頻度が異なるため、利用頻度などで分類しておく
  • 後々、仕様変更の可能性もあるため、追記・修正できるよう設計書ももちろん引継いでおく。

7.移行フェーズ

  • 完成したシステムを利用者が利用できるように切り替えることを本番展開、新システム移行と呼ぶ
  • 新システムの追加と既存システムの更改では、注意点が異なる
  • 新システムの追加:新たな作業が発生するため、説明が必要、既存システムとの蓮駅がある場合切り替え時の調整・テストが必要
  • 既存システムの更改:データを引き継ぐ場合、移行期間が必要。平行運用の場合は最新データの扱いを決める必要がある。コンチプランが必要
  • 移行には一括移行、段階移行、平行運用の3つの方式がある
  • 移行時に問題が発生する可能性があるため、事前に移行継続の判断者を決めておく
  • 同時に、移行を継続するかを判断する基準を明確にしておく

最後に

異動、転職などで情シスの社員として仕事を始めることになった場合、初めて経験することが多いのはもちろん、使われている言葉の意味すらわからないこともあります。

そもそも社内でどのような機器・構成でどのようなシステムを運用しているのかさえ知らないところから始まります。

わからない部分は都度調べたり人に聞きながら明らかにしていくしかないのですが、

システムに関する仕事で共通項とされる部分や基礎的な知識を押さえておくことができれば、覚えも慣れも早くなるでしょう。

そして、今後同じ仕事を始める後輩の助けとなるよう、自分が苦労した部分はドキュメントに起こしておくことで、課として、部門としての成果も上がっていくことにつながります。

今回参考にした本は、運用設計をテーマに据えていたため、内容もそちらを中心にしたものとなっています。

インフラ、アプリ側での構築についてもより詳しく学習する必要がありそうです。

Kindle Unlimitedで読書の習慣をつけよう

すでに紹介している通り、今回参考にした書籍はKindle Unlimitedの対象です。(2020年8月現在)

休日はソシャゲで時間を潰すこともできます。

旅行に行くことだってできますし、趣味に時間を使うこともできるでしょう。

どれも今の楽しさを提供してくれますが、後々に活きてくることはありません。

毎日とは言わずとも休日に少し読書の時間をとってみる。それを積み重ねて月に1冊読んでみる。

たったこれだけで、後に自分の身を助けてくれるはずです。

そして、月に1冊読書できるペースであればKindle Unlimitedに登録すると良いです。

月に1冊読むことができれば元が取れます。2冊も読めばお釣りが返ってきます。

好きな本をダウンロードしてちょっと読む。興味がなければ別の本を取ると言ったことも可能です。

不景気を控えた今の時期から、読書を習慣づけてみませんか?

情シス
シェアする
柳をフォローする
Best Practice

コメント