【本記事は、Insight Edge アドベントカレンダー、Insight Edge Advent Calendar 2025 の20日目です】
こんにちは。Insight Edgeに6月に入社した肥塚です。
QA・運用保守チームの第1号社員としてシステム運用に携わっています。
この記事では、入社時に存在していた弊社のシステム運用の課題と、その課題をどのように解決しようとしているか説明しようと思います。
システム運用に携わるエンジニアの方々や、システム運用の体制を強化したいマネージャーの方々に特におすすめの記事です。
直面していた危機的状況
私が入社したとき、システム運用分野の問題がいくつか存在していました。詳しくみていきましょう。
1. 属人化の連鎖：「担当者しかわからない」の恐怖
弊社では、開発チームによる商用開発を経て顧客とライセンス契約を結び、システムを本番提供しています。それで弊社のお仕事が終わりなわけではなく、ライセンス契約において定められている顧客からの問い合わせにきちんと対応する必要があります。その対応にあたっては当該システムの運用保守に関する広範な知識が必要になります。例えば:
- 契約書を配置してあるGoogleドライブのURL
- SLAの有無やその内容
- 開発を担当したのは誰か
- 本番環境のURLは何か
- 監視はどのようにされているか
これらはシステムの運用保守にあたって適切に整理されておらず、当時の開発担当者だけが知っている状態でした。
特に開発担当者の不在時に保守運用が属人化したシステムの問い合わせが来ると、対応が困難になります。残された人たちはシステムの概要さえも知らないので、問い合わせに対応するのに苦慮します。
2. ライセンス契約を結んで提供しているシステムの一覧がない
管理職としてはライセンス契約を結んで提供しているシステムの一覧によりそれぞれの運用保守の状況を概観し、次なる施策を考えたいところです。 しかしつい最近まで弊社ではそのような一覧が存在しない状態でした。
一覧がないと管理上何が良くないかというと、例えば:
- 経営層にライセンス契約を結んでいるシステムが何個あるのか報告できない
- 保守運用の管理対象とするシステムがわからず、社内で聞いて回る必要がある
- それぞれのシステムの契約更新日がわからないので更新漏れのリスクがある
- システムの属人化解消にあたって優先度を立てられない
などの問題があります。
そんななかQA・運用保守チームが立ち上がり、私が第1号社員として入社して以降、運用保守の基盤を構築し、1番目と2番目の課題を一度に解決する仕組みを実装しました。
運用保守の基盤
ナレッジの一元化「運用保守マニュアル」
弊社が言う運用保守マニュアルとは、顧客とライセンス契約を結んだシステムを対象に作成した技術的なドキュメントです。「〇〇システムの運用保守のことは〇〇の運用保守マニュアルを見ればわかる」ドキュメントを目指しています。システムに関する情報を「基本情報」「ビジネス情報」「技術情報」「運用情報」の4つのカテゴリに分けて羅列的に記述した社内向けのドキュメントです。
# (プロダクト名) ## 基本情報 ### プロダクト名 ### 案件名 ### 顧客名 ### 契約形態 ## ビジネス情報 ### プロダクトの目的 ### 契約書 ### 開発提案書 ### SLA ### 契約開始日 ### 契約更新予定日 ### 1月あたりの問い合わせ対応の上限時間(h) ### 1月あたりの問い合わせ対応の上限時間の補足 ### 先方ご担当者 ### セールスコンサルタント ## 技術情報 ### 開発時の体制 ### インフラ構成図 ### リポジトリ ### 認証 ### AIモデル ### AIモデル情報 ## 運用情報 ### 本番環境のアクセス情報 ### 検証環境のアクセス情報 ### 問い合わせ窓口 ### 顧客連絡用メーリングリスト ### 運用保守業務 ### 監視 ### 障害対応 ### 運用の外部委託状況 ### 開発用Slackチャンネル ### 運用保守用Slackチャンネル ### アラート用Slackチャンネル ## その他資料
弊社では社内向けのドキュメントを管理する方法として:
- Confluence
- Googleドライブ
- SharePoint
- Slack
- GitHub
これらの中から運用保守マニュアルを管理する方法を選ぶ必要がありました。
その中で、我々はGitHubを選択しました。選定理由は以下です。
- 運用保守マニュアルのレビュー体制を担保するため
- 運用保守マニュアルは重要なドキュメントなので、編集前にレビューが必要です。Confluence等では十分なレビュー仕組みがないため、GitHubのPull Request機能によってレビュー体制を整えました。これは運用保守マニュアルの編集者が、Git/GitHub操作に慣れたエンジニアであるという前提のもとでの選択です。
- 運用保守マニュアルは一度書いてしまえば変更されることが少ない「静的」なドキュメントであるため
- Git管理だとスプレッドシートよりも変更コストが高くなりますが、運用保守マニュアルは一度書けば変更されることは少ないため、変更コストの高さは問題にならないと考えました。
- 運用保守に間接的に関連するメタ的な情報（例えば問い合わせや案件の動き等）は運用保守マニュアルに記載せず、別途スプレッドシートで管理しています。
- Docs as Codeの原則を実践できること
- Docs as Codeとは、コードを書くときと同様の道具を使って技術系のドキュメントを書く考え方です。詳細はhttps://www.writethedocs.org/guide/docs-as-code/ をご覧ください。
- 運用保守マニュアルこそ技術系のドキュメントなのだから、Gitとマークダウンを使って記述し、変更の都度コードレビューがあるべきだと考えました。
- CI/CDパイプラインを利用できること
- GitHubをリモートリポジトリに使う場合は、GitHub ActionsをCI/CDパイプラインとして利用できます。それらを運用保守マニュアルの品質向上に役立てています。
- CIパイプラインとしてはmdファイルのlint, 運用保守マニュアルに付随するスクリプトのテストコードを実行するものなどがあります。
- CDパイプラインとしては運用保守マニュアル記載の情報を抜粋してBigQueryに同期する（後述）ものなどがあります。
- 運用保守マニュアルを静的サイトとして公開できる
- 運用保守マニュアルはマークダウンファイルなので、GitHub Pagesで簡単に公開できます。今回はmkdocsで静的サイトをビルドしています。
- リモートリポジトリを信頼できる唯一の情報源（Single Source Of Truth: SSOT）として扱うことができるため
- システムの運用保守に直接的に関連する情報をリモートリポジトリに集約することで、リモートリポジトリをSSOTとして扱うことができます。リモートリポジトリがSSOTであるため、リモートリポジトリで管理する情報から派生してCDパイプラインから色々な成果物を作成することができます。後述する「サービスポートフォリオ」がその一例です。
サービスポートフォリオ
弊社が言うサービスポートフォリオとは、顧客とライセンス契約を結んで運用保守に入ったシステムの一覧のドキュメントです。毎週の運用保守定例にて参照されます。運用保守を管理する上では、運用保守対象のシステムの一覧が重要です。
さて、どのようにサービスポートフォリオを作成すれば良いのでしょうか？手動で作成して管理するのも一つの手ですが、少ないリソースで管理するためには手作業をできるだけ排除することが重要と考えました。そこで、運用保守マニュアルからサービスポートフォリオを自動的に作成する仕組みを構築することにしました。運用保守に入っているシステムそれぞれに対して運用保守マニュアルが作成されていれば、サービスポートフォリオで運用保守対象のシステムが自動的に網羅されるためです。
実際にその仕組みはどのようなものか、以下に簡略化したアーキテクチャを示します。
このアーキテクチャにより、運用保守マニュアルを管理するSSOTのGitHubリポジトリのmainブランチにマージされると:
- GitHub ActionによりPythonスクリプトが実行され、BigQueryテーブルに運用保守マニュアルの一部データが自動連携される
- BigQueryテーブルと接続したGoogleスプレッドシートのコネクティッドシートのサービスポートフォリオに自動連携される
という仕組みが実現されます。作成途上の運用保守マニュアルは更新頻度が高く、自動化しておいてよかったと強く感じています。
成果と今後の展望
Insight Edgeに入社してから邁進してきた施策の一部をご紹介しました。 まだまだ発展途上ですが、運用保守マニュアルとサービスポートフォリオという仕組みを作った効果により、Insight Edgeにおける運用保守の進め方が少しずつ定義されるようになってきました。例えば:
- システムの問い合わせが来たとき、そのシステムの運用保守マニュアルを参照することで、運用担当者が問い合わせに対応しやすくなった
- サービスポートフォリオによって週次の運用保守定例で各システムの運用保守の状況を概観できるようになった
最後に今後の展望を述べたいと思います。 特にこの記事で紹介した運用保守マニュアルとサービスポートフォリオに関する展望は以下です:
- 各案件の運用保守マニュアルの品質向上
- 顧客とライセンス契約を結んでいる全システムの運用保守マニュアル数十個を作成しましたが、空欄だらけの運用保守マニュアルが多く、品質に課題があります。
- 運用保守マニュアルの品質の定量評価とKGI/KPI作成
- この記事では述べませんでしたが、CDパイプライン上で運用保守マニュアルをAIで品質評価する仕組みを構築しています。それによって、一貫した評価基準により運用保守マニュアルの品質を定量的に評価することが可能になっています。
- 今後は、全ての運用保守マニュアルの品質を高めるというKGIを試験的に策定し、それに対するKPIを表すデータモデルをダッシュボードで可視化するということに挑戦しています。KPIはひとまず
高評価率 = LLM評価が8点以上の運用保守マニュアルの件数 / 全運用保守マニュアルの件数と定義しており、現在はこのKPIの数値が3%しかない状態です。KPIの数値の目標はまだ定めていませんが、早くこの数値を上げるべくチームとして施策を講じているところです。
いかがだったでしょうか？ この記事が、読者の方々の運用保守の悩み事を解決するヒントとなれば幸いです。
