チケット駆動開発の課題～ITILやDevOpsの適用方法

Redmineなどのチケット管理ツールをタスク管理ではなくインシデント管理で運用する場合、従来の手法ではうまくいかない場合が多いし、そのような経験をたくさんしてきた。
思ったことをラフなメモ書き。

【1】例えば、自社でAmazonや楽天のようなショッピングカートのWebシステムを持っているとしよう。
すると、新しい機能を追加していく開発チームと、Webシステムのインフラ構築やインフラ周りの監視に関わる保守チームの2つのチームが自然に体制として現れる。

システムは自動車などの製品とは違って、リリースした後、ユーザに使われてからが本当の本番だ。
何故なら、システムが稼働して初めて、ショッピングカートにクレジット決済などで現金が入り、売上が上がっていくからだ。

システムが使われていくと、ショッピングカートの動きがおかしい、ここのユーザインターフェイスが使いづらい、404エラーが出た、突然画面に接続できなくなった、などたくさんの障害やら、単なる問合せと思っていたのに重要な障害だったと判明するような問合せが毎日届く。
保守チームはこのような問い合わせに対し、1つずつ調査してはユーザに回答したり、障害と判明すれば開発チームに修正依頼を出して緊急リリースしたりする。
特に、Exceptionが出たとか、画面に表示される利用金額が狂ったとか、個人情報が漏れたとか、システムや会社の信用に関わる障害が発生したら、即座に対応しなければならない。

だから、保守チームはコールセンターのように電話受付やメール当番もしながら、サーバーの保守や監視、開発作業をするのだから、とても忙しい。

プログラミングの開発とサーバーインフラの構築はそもそも技術が全く違う。
SSL、セキュリティ周り、Zabbixなどの監視ツール、FireWallやBigIPなどの切り分け、Apacheの負荷分散、RAID5によるHDD分散によるバックアップなど、単なる開発とは違う技術が必要とされる。

また、開発チームへの連携も意外とうまくいかない時が多い。
2つのチームメンバーに要求される役割も違うのでお互いを理解し難いし、一つのインシデントに関わる人が多いほど、伝言ゲームになりがちで無駄が発生しがち。

つまり、開発チームと保守チームは、元々風通しが悪く、そのためにリリース間隔が長くなりがちな状況がとても多い。
それが原因でシステムが大規模化し複雑化するほど、リリースサイクルが長くなり、障害も多発しやすい。

そのような状況を解決するために、ITILのような運用保守フレームワークや、開発チームと保守チームは一体化すべきだというDevOpsのような考え方が出てきたのだと思う。
だが、そのような考え方を実際の現場に適用する場合、そう簡単に当てはまるとは限らない。

【2】ITILのようなIT運用保守フレームワークでは、インシデント管理→問題管理→変更管理→リリース管理でプロセスが流れていく。
普通の現場でITILを適用する場合、インシデント管理は保守チームが担当し、問題管理以降は開発チームが担当する時が多い。
何故なら、実際のシステムの機能を修正するなら開発チームが担当するからだ。
但し、HDD故障が障害の原因ならば、問題管理以降は保守チームが引き続き担当するし、OracleやWebSphereなどのようなミドルウェアに障害があるならば、ベンダーに作業を依頼し、保守チームが変更管理プロセスでリリース計画を立てるなどの作業をするだろう。

つまり、問合せの内容によっては、プロセスを担当するチームや関係者が変わってくる。
また、一つの問合せは、状況に応じてステータスが頻繁に変わる。
今は誰がボールを持って担当しているのか、今何が課題なのか、をリアルタイムに追跡できる仕組みがなければ、ITILは絵に描いた餅だ。
普通はExcelのインシデント管理表から、ステータスが変わるたびに別のExcelの問題管理表、変更管理表へ転記されて、どんどん複雑化していく。
この問合せは結局、何が原因で、どのように解決したのか、という結論を知りたいだけなのに、延々と経過報告ばかり読まされたりする。
せっかく蓄積されたインシデントや障害管理票のデータを生かしきれていないチームはとても多い。

【3】実際の運用保守プロセスは3層構造が多いと思う。
まず、問合せを一次受付するインシデント管理。
その問合せをまず事前調査して、FAQやWikiを参照すればすぐに回答できる問題なのか、あるいは、再現性がなく時間が掛かる根深い問題なのか、あるいは、ハードウェア故障やネットワーク回線の問題ゆえにベンダーに更に調査依頼すべきなのか、を判断する問題管理。
そして、障害修正や問題解決の方法が確定している前提で、リリース計画を立てて修正とテストを実施し、デプロイ＆リリースしていく変更管理とリリース管理。

ここで一番重要なプロセスは、問題管理プロセス。
何故なら、問合せに対して、できるだけ早く問題解決の方針を立てたり、優先度を付けるプロセスだから。
この問題管理プロセスで時間がかかると、大したことがない問合せが実は個人情報漏れやシステムの故障につながり、会社の信用に関わる重大な障害を引き起こしたりする場合がある。
だから、問題の原因と解決方法を早く的確に示すことが重要。

だが、日々の問合せは結構多いために、一つの問合せに対する解決方針を立てる作業は時間が掛かりがち。
保守チームはそもそもコストセンターなので、さほど優秀な人員が多いとは限らないし、人数も少ない。
リリース直後は問い合わせが多いだろうが、システムが安定稼働していれば暇なので、人が多く張り付くと赤字になるから。
この問題管理で判断を間違ったり、問い合わせ対応の優先度を間違えると、保守チームだけでなく開発チームの作業負荷が多くなり、最終的にはシステムの機能改善や障害対応に支障をもたらす。

【4】Redmineのようなチケット管理ツールでITILを運用する時、タスク管理や課題管理とは異なるノウハウが必要だと思う。
インシデント管理からリリース管理までのそれぞれのプロセスはワークフローが全く違う。
変更管理以降のプロセスは普通のタスク管理に近いが、インシデント管理や問題管理は、JiraやTracで使われる課題管理に近い。
だから、一つのワークフローで全てのプロセスをカバーしようとすると、現場でうまく作業が流れない。

また、ITILのような運用保守では、チケット集計機能がとても重要だ。
今日までインシデントは何件発生して、どれだけ未対応なのか。
このインシデントは誰が担当していて、今どんな課題を抱えているのか？
直近1ヶ月のインシデントを集計すると、どのような傾向が見られるのか？
それらの集計結果や過去の対応ノウハウを蓄積したら、特定の日に発生する障害を事前に見つけることができたり、定期的に対応した方が良い運用作業へ落としこむのができるのではないか？

個人的には、Redmineはチケット集計機能が弱い。
むしろ、JiraやTracの方がチケット集計機能が強い。

また、チケットをインシデントや変更管理のタスクにどのようにマッピングすればいいのか、という問題もある。
インシデント管理・問題管理・変更管理(＋リリース管理)の3層構造のプロセスをどのようにチケット管理へ適用すると良いのか？

一つのチケットで3層構造のプロセスを当てはめるのは多分うまくいかない。
ステータスが増えすぎて分かりにくいし、作業者が混乱しやすい。
また、チケットがなかなか完了しないので、チケットがどんどん増えていき、チケットの重みで破綻する。

インシデントを親チケット、問題管理以降のタスクを子チケットで管理する方法もあるが、運用が複雑になりがち。
子チケットはどんどん増えるし、全ての子チケットが完了しなければ、親チケットのインシデントは完了できない。
例えば、問い合わせに対し暫定対応したものの、本格対応は更に調査が必要だったり、多くの工数がかかるため延期する場合、インシデントのチケットは残ったままになる。
すると、完了できないチケットはどんどん増えていき、優先度を付けることすら難しいぐらいチケットが氾濫してしまいがちになる。

また、実際の運用では、インシデントだけを集計して、問合せの発生源や原因、種類などを傾向分析したいものだ。
なのに、一つのチケットで複数のプロセスを表していると、集計しづらいし分かりにくい。

僕が今ベターと思える運用方法は、インシデント管理・問題管理・変更管理(＋リリース管理)のそれぞれのプロジェクトをRedmineの親子プロジェクトにマッピングし、それぞれのプロセスを独立したチケットで管理し、細かな作業タスクはそれぞれのプロセスのチケットの子チケットで管理するやり方。
それぞれのプロセスは、担当するチームや関係者が異なる時が多いし、それぞれのプロジェクトでチケット集計すれば、ステータスや工数、傾向分析の集計がやりやすいからだ。
但し、チケットがその分細分化されるため、煩雑になるトレードオフはある。

【5】DevOpsという概念はとても過激な概念だと思う。
リリースサイクルを3ヶ月に1回から1ヶ月に1回、1週間に1回、1日に数回などのようにどんどん短くするには、一人ないし少人数で、開発からデプロイ・リリースまでの全てのプロセスを担当できるようにならなければ、絵に描いた餅だ。

開発と運用の新しい関係、「DevOps」とは何か？ － Publickey

「開発と運用の一体化」という言葉はとても美しいが、それを本当に実現するならば、開発メンバーはインフラチームの仕事もできるし、保守メンバーは開発チームの仕事もできるような文化にしなければならない。
例えば、プログラミングもできるし、自分一人でサーバー構築できるし、HDD交換やネットワークの配線設置作業もできるマルチな能力をメンバー全員が持つような状況を指す。

DevOpsを実現するには、ツールと文化が必要と言われるが、その理由は、ツールによってインフラ周りをできるだけ自動化して誰もが簡単にリリースできるようにすること、そして、開発メンバーとインフラメンバーが協力して作業できるような環境が必要であることを示唆しているからと思う。

最近のDevOpsの記事などを読むと、AWSなどのクラウド、Chefなどの環境構築ツール、Jenkinsなど万能のジョブ管理ツールを駆使して、プログラムを書いたら即座にリリースできるような仕組みがあって初めて実現できるように思える。
つまり、HDD故障やネットワーク回線の混雑などの意識しないようなインフラを構築できれば、開発チームがインフラチームを兼ねるDevOpsないし、そもそもインフラ運用など不要というNoOpsが実現できるわけだ。

Scrumではフィーチャーチームと呼ばれる概念があり、大規模プロジェクトで複数チームがScrumを運用する時、作業単位や工程単位ではなく、機能単位のチームを作り、一つのチームがなんでもできるような体制を作る。
DevOpsの概念は、Scrumのフィーチャーチームを実現ないし補強する概念だと思う。

フィーチャーチーム: プログラマの思索

つまり、開発者がインフラ構築ないしリリース作業もできるような多能工になることで、Scrumのフィーチャーチームという体制を組むことができる。
でも、僕はそのような経験がないので、Scrumのフィーチャーチームで回すために必要な制約条件が何か、はまだ分からない。
おそらく、そう簡単な適用方法ではないだろうと思っている。