システム運用を改善するにはチケットシステムを使え!

システム運用を改善するにはチケットシステムを使え!

スポンサーリンク

お仕事でBacklogというチケットシステムを使っているのですが、運用のチケットがほとんどない状態でした。
それでもシステム運用がうまくまわっているのであれば、まぁ、そのやり方に口を挟まないでおきましょう。でも実際は、いろいろと問題が起きてたいへんな状態。たいへんそうなんだけど、どんな問題があってどんな状態になっているか、週一回の進捗会議でしか確認できていないという。
「とにかくチケットを書くようにしてくれ」と何度言っても書こうとしないので、PowerPointで資料を作って配布し、社内勉強会を企画して説明もしてみました。が、結局定着しませんでした。開発チームの一担当に過ぎない自分が運用チームのメンバーに対して強制するわけにもいかないので、これ以上の活動は無駄です。

そのままボツにするのももったいないけど、そのまんまブログに載せるともめそうなので、書き直して記事にしました。

システム運用とチケット

チケットシステムがシステム運用に必要なわけ
チケットとは?

Backlogを導入しているくらいだから「チケット」を知らないということはないでしょうけど、一応。

チケットが必要なわけ

「ある事象が他の事象の原因となっていることがある」

という記述をみたことがあります。つまり、複数人でシステムの運用に当たっている場合、自分が直そうとしている事象が他の人の仕事に影響をあたえることがあるということです。
この場合、適宜状況を更新していかないと、他の人の仕事を止めてしまうことになります。

また、今までの課題を

  • いつ頃発生するのか
  • どの部分で発生するのか
  • どんな内容が多いのか

と分析するためにも、チケットは必要です。
日報や週報を提出することになっているところも多いと思いますが、

  • 状況の更新は日単位または週単位なので、タイムリーとは言いがたい
  • 「人」単位の情報となるため、複数人で課題の対応に当たっている場合、情報が分散して課題の状況が見えにくい
  • 報告ラインにいない人には情報が届かない

といった問題があります。

システム運用から見たチケットの利点

SRE本にもあるように、何度も行われる作業は自動化を検討すべきですが、その根拠になります。

また、対象システムでの作業内容が記されるので、検索して見つかる一般的な内容よりも、具体的な内容になります。

チケットの書き方

チケットの書き方

書くべき理由をあげたので、次はどう書くかという話をしましょう。

チケットを書くタイミング
チケットに書くこと

問題の解決方法がいくつかあることがあります。
「よくよく考えたら使えないことがわかった」という方法も、その理由とともに書いておきましょう。将来、また同じ考えをする可能性は高いです。

「どんな操作をして、どんな出力があった」というログも重要です。同じ問題が発生したとき、解決に向けて適切に進んでいるかを確認するとき、頼りになります。
単に「やりました」というような内容しかないチケットは、個人のメモです。問題の傾向をつかむには役立つでしょうけど、未来の自分の手助けはしてくれません。

「テンプレートを用意しておく」というアイディアもありますが、そもそもチケットを書くことが定着していないところでは、ハードルを上げるだけになってしまいます。

チケットの鉄則

これ、非常に重要です。
問題の進捗状況をチケットで追いかけるので、複数の問題がチケットに含まれていると、進捗状況がわからなくなります。
関係している問題かどうか判断がつかないのであれば、別のチケットにしておいたほうが処理しやすいです。

チケットを活用するために

チケットを書く理由(再び)
  • 傾向を分析するための資料とする
  • 同じ作業を再び行う際、具体的な資料として活用する

溜めたチケットを有効活用するためには、検索が重要になります。
類似語検索ができないチケットシステムも多いので、チケットを書くとき、ちょっと工夫をしましょう。

チケットを活用するための工夫

いろいろなメモを書いたファイルをチケットに添付するというアプローチもありますが、添付ファイルの中まで検索してくれるチケットシステムは(多分あるのでしょうけど)知りません。画像を貼り込んだ手順書ならまだしも、作業メモ程度だったら内容をチケットに書いたほうがいいです。

チケットを「対応完了」にする

チケットシステムには、チケットの状態を設定する機能があります。

  • 未対応
  • 処理中
  • 処理済
  • 完了

など、システムやプロジェクトによって違いはあるものの、どんな状態かがすぐにわかる、便利な機能です。
どういった基準で誰が状態を変えるのか、あらかじめ決めておきましょう。

  • 取り掛かるときに「処理中」にする
  • 終わったら「処理済」

は普通だと思いますが、「完了」にするのは明確なルールを設けておくべきです。
特に、 Backlogでは、チケットの「シンプルな検索」では、「完了」は特別扱いです。「完了以外」がdefaultの条件になっているので、完了にされたチケットは検索結果にでてきません。

  • チケットを起こした人が確認して、「完了」にする
  • 完了にする際、チケットを起こした人に対して通知を飛ばす

といった工夫が必要でしょう。
毎週振り返りの打ち合わせを設けて、その場で「完了」にしていくのもよさそうです。

最後に

Ship It!

今、問題追跡システムを導入していないならば、すぐに導入してください。

Ship It ! 第2章 5 問題の追跡

とあるように、チケットシステム(問題追跡システム)の活用は重要です。
Ship It! は主に開発の話をしていますが、今日のベストプラクティスは、コードを書く現場からのものが多いですし、応用できることもいろいろあると思います。

など、無料で使えるチケットシステム(BTS)も数多くあります。

  • 「今」を見える化する
  • 「将来」の作業の参考資料にする

この2つの効果があるので、システム運用でもチケットシステムを活用してください。

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存

フォローする

この記事へのコメント

Loading Facebook Comments ...

No Trackbacks.