Redmine for ITILが解決するもの
ホロンテクノロジーという会社がRedmine for ITILというソリューションツールをPDFで公開していた。
とても参考になる資料だったので、システム運用保守におけるRedmineの解決方法について、考えたことをメモ書き。
ホロンテクノロジーが提供するOSSソリューションのご紹介 (PDF)
Redmine for ITILの特長|株式会社ホロンテクノロジー
Redmine for IMSの特長|株式会社ホロンテクノロジー
Hinemos+Redmine for ITILで運用保守を改善する: プログラマの思索
チケット駆動開発の課題~ITILやDevOpsの適用方法: プログラマの思索
【1】システム運用保守の問題点
システムの新規開発案件ではなく、システムの運用保守では特有の問題点がある。
(1)完全化保守や適応保守が難しい
本番運用している業務システムは安定稼働が命だ。
しかし、実際の運用現場では、色んな障害が毎日のように起きる。
HDDが壊れたり、ネットワーク回線の通信速度が突然ダウンしたりするハードウェア障害。
SIで新規案件を無事にリリースしていくたびに、保守する対象のシステムは飛躍的に増えていく。
しかも、サーバーは3年おきにリプレースする時が多い。
メモリの増設、HDDの交換、ネットワーク回線の高速化など、動いているのにシステムをいじって、システムをダウンさせてしまう場合が多い。
予防保守とは「リリース後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正」のことだが、実際の現場では、障害も起きていないのに、上記のような事情で是正対策を実施せざるを得ない。
そんな保守作業は、完全化保守や適応保守と呼ばれる。
適応保守とは「ソフトウェア製品を使用できるように保ち続けるため、ソフトウェア製品の引渡し後に製品を修正する」保守作業。
完全化保守は「性能や保守性を向上させるためにソフトウエアを改良する」保守作業。
つまり、完全化保守や適応保守は、稼働中のシステムを生き延びさせるために必要な保守作業を示す。
しかしながら、完全化保守や適応保守の作業で、障害を自ら起こしてしまいがち。
それら保守作業のノウハウが蓄積されず、日々追われているのが実情ではないだろうか?
(2)運用コストがどんどん大きくなる
運用中はHW障害だけでなく、アプリの障害、社外の外部接続サーバーからの異常データ送信など、ソフトウェアの障害もある。
そんな障害が発生するのを抑止するために、障害フォロー手順をやリリース手順をコマンドで自動化したり、マニュアル化する時が多い。
しかしながら、リリースしたサーバーの冗長化、社外のサーバーからの外部接続、業務データは、稼働するほどどんどん増えていく時も多い。
すると、実際のマニュアルやコマンドを情報共有するのが難しくなってくる。
運用作業のオペレーションミスが結構多くなってきている。
運用ノウハウが属人化してしまい、情報共有や作業の引き継ぎがやりにくくなってきているのだ。
(3)障害検知後の連携が悪い
システムの安定稼働を保証するために、監視ツールでpingやヘルスチェックなどで検知する仕組みを作るのが普通。
だが、障害検知のメール送信機能ぐらいで、その後の調査やソース修正への情報連携がスムーズでない。
Excelの障害報告票をメールでたらい回しにする場合が多いから、どれが最新の情報なのか、すぐに分からなくなる。
【2】Redmine+ITILによる解決策
システム運用保守のマネジメントフレームワークであるITILの考え方をRedmineと組み合わせる場合、以下のような方針でシステム運用保守に導入するとよい。
(1)障害や問合せ、改良作業など全てはチケットで一元管理する
障害、問合せ、サーバーのリプレース、ソフトウェアの機能改善など全てをチケットに登録して記録していく。
チケットに作業記録が残るので、後から参照できる。
チケットのステータスで問合せや障害の状態を管理すれば、チケットのワークフローで一括管理できる。
途中で、担当者を入れ替えたり、ステータスの更新を権限でチェックすることも可能。
また、チケット集計機能を使えば、障害一覧や問合せ一覧、期限間近のタスク一覧など、多種多様なレポートを出力できる。
リーダーは毎月の報告書作りや、毎日の進捗チェックに活用できる。
(2)監視ツールの障害検知は、メールによるRedmineのチケット自動登録機能を適用する
Zabbixなどの監視ツールが検知した障害をメーリングリストへ送信する時に、Redmineにもメール送信すれば、チケットを自動起票できる。
チケットの起票漏れがなくなるし、一度チケットに登録されれば、誰かが気づいてくれる。
チケットの発行を起点とした後は、インシデント管理→問題管理→変更管理への流れをチケットのステータス管理でマッピングすればいい。
Redmineのチケット登録をITILへ応用する: プログラマの思索
メールでRedmineチケットを登録する機能の可能性: プログラマの思索
メールでRedmineチケットを登録する機能のアーキテクチャ: プログラマの思索
(3)共有したい情報はWikiを積極的に使う
運用保守では、毎日のアクセスログチェック、毎月末のログ集計からの報告などの定形作業がとても多い。
それらの運用手順はWikiにまとめておくと、ブラウザで閲覧しながら作業できる。
もし手順に変更があれば、Wikiですぐに編集すればいい。
また、ネットワークやシステムの設定情報、定型的なリリース手順もWikiで公開しておくと良い。
Wikiの利点は全文検索できることなので、分からなければ、まずは検索すればいい。
作業の引き継ぎもWikiがあれば、やりやすくなる。
【3】Redmine導入による効果
Redmineを導入すると、副次的効果も出てくる。
(1)チケットやWikiで見える化
作業の見える化は、コミュニケーションの促進をもたらす。
過去の障害や問合せをチケット番号で話すことで、お互いの認識が共有しやすくなる。
チケット駆動開発のプラクティスである「No Ticket, No Work」や「Ticket First」を運用していれば、チケットの起票と共に作業が始まり、チケットをキャッチボールしながら作業するようになる。
複数人が一つのチケットに関わることで、2つの目による品質チェックが有効に効く。
ホロンテクノロジーが提供するOSSソリューションのご紹介 (PDF)の17ページ以降に、Redmineの運用方法を詳しく解説している。
(2)トレーサビリティによる効果
Redmineには関連チケット、親子チケットなど、チケットを関連付ける機能がある。
この機能を使えば、並行で作業しているチケット、過去と同じ事象のチケット、同一人物による問合せチケットなどを相互リンクすることで、作業の理解を促進できる。
また、ソースのリビジョンとチケットの連携により、ソース修正の発生理由をチケットから辿ることもできる。
運用保守は少ないメンバーで数多くのタスクを回すから、人の出入りも激しい。
いなくなった人の運用ノウハウは口頭の説明だけでは引き継がれない。
トレーサビリティは、特にその後の運用保守やリバースエンジニアリングで大きな威力を発揮する。
(3)変化に適応
チケットは変化に強い。
日々の状況に応じて、ステータスや期日、内容、マイルストーンを更新して記録していく。
チケットを最新化する運用さえ徹底できれば、チケット集計機能によって、リーダーはリアルタイムに作業状況を把握できる。
【4】Redmine+ITILを適用して判明した課題
(1)ITILをそのまま運用すると、ワークフローが複雑になる。
インシデント管理→問題管理→変更管理→リリース管理という流れは、一つのインシデントを4つのチームでやり取りするので、ステータスがとても多くなる分、複雑になりやすい。
ITILをガチガチに運用して複雑になるよりも、現場の体制に合わせて、ステータスを減らして、気軽に回せるワークフローを構築した方がいい。
(2)問合せないし検知されたインシデントから発生した変更要求は、CABと呼ばれる会議体で対応方針を決定するように運用する。
ITILのCABは、リリース確認会の合議体に相当する。
この場で、全員からレビューを受けて承認されなければ、そもそもリリースできない。
ITILのCABが、複数チームに関わる課題を調整したり、変更要求の修正の順序を決めたりする。
このCABがしっかり運営されないと、せっかく登録されたチケットが完了まで上手く回らない。
ホロンテクノロジーが提供するOSSソリューションのご紹介 (PDF)の12ページでは、チケット駆動型事案管理のワークフローイメージとして、「解決策確認会」というステータスが用意されているが、それがCABに相当する。
初心者歓迎! ITIL連載講座:ITインフラの変更管理プロセス (2/4) - ITmedia エンタープライズ
(3)チケット集計機能はもっと強化した方がいい。
普通は、障害報告票を真似て、チケットの属性をカスタムフィールドで増やし、障害報告に使えるようにする。
特に重要なのは、ワークフローに相当するトラッカー機能だ。
障害の種類、問合せの種類に応じて、トラッカーを作って運用した方が、チケットのテンプレートを切り替えしやすいし、ワークフローを微妙に変えることもできる。
でも、チケットの入力が煩雑になる弱点もある。
だから、チケット入力とチケット集計を天秤にかけて、運用がうまく回るように注意すべき。
【4】感想
ソフトウェア運用保守こそ、RedmineのようなITSが使われるべきだと思う。
なぜならば、現場の開発プロセスをサポートするような機能がITSにふんだんに揃っているからだ。
上記のような問題を解決するためにRedmineを導入する場合、自分たちで作りこんだ独自のプロセスとセットで運用することも可能だろう。
やり方はいくらでもある。
Redmineによるチケット駆動開発には、数多くの可能性が秘められている。
| 固定リンク
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント
いつも精力的な執筆,まことに感心しています.なのでたまにはコメントをしようかと.2,3年前に,RedmineでITIL運用をどうしようか?と,仕様を設計したことがあります.しかし会社の運用組織がそのレベルに達していなかったこともあり,採用しませんでした.他に運用ツールもあったし.3年前だったか,ホロンの担当者に聞いたことがあります.プラグインでは対応できない部分があり,Redmineの一部ソースコードを改変したそうです.NTT◯ータグループには専用のITILツールがあるので,今後も採用することはないでしょうが,小規模でもITILに前向きな組織にはいいんじゃないかと思います.
投稿: 町井昌徳 | 2013/08/09 10:55
◆町井さん
運用保守は新規開発とは違う問題点があり、Redmine+ITILでうまく解決できる部分と、ツールだけでは難しい点があります。
ITILの弱点は関係者が多くて、ワークフローが複雑になりすぎる点があると思います。
この辺りのアイデアや考えたことも、次回以降の勉強会で話してみたいと思います。
投稿: あきぴー | 2013/08/10 23:16