カスタマイズに関する自分用メモ。
新しいワークフロー:waiting
「リリース待ち」。
システムがリリースされている状態でチケットをざくざくクローズしていたときに、クローズしたはずのチケットと同様の不具合報告がされました。調べてみると、クローズしたチケットの修正を適用していなかったという単純な問題でした。その経験から生み出されたワークフロー。
リリースノートを書くときや、次のリリーススケジュール決めるときに非常に便利です。
trac.iniを直接いじらなきゃいけないのが面倒ですが。
Google のデータセンター運用から学んだ、新しい不具合の重要度分類
The Datacenter As a Computerに、Google のデータセンター運用における不具合の重要度分類が書かれていました。(p.80)
| Corrupted | データが破壊され、復旧困難 |
| Unreachable | サービスがダウンしているか、ユーザからアクセスできない |
| Degraded | サービスは動いているが、何らかの縮退モードになっている |
| Masked | 障害が発生しているが、ユーザからは完全に隠蔽されている |
非常にわかりやすかったので、早速tracの重要度分類に採用してみました。といってもそのまま重要度に書き込んでしまうと他の分類のチケット(タスク等)が意味不明になってしまうので、重要度には「最高、高、中、低」のみ記載し、フロントページにその意味を記述することに。
| 重要度 | 説明 | 例 |
| 最高 | データ破壊 | オペレーションミスによるマスタDB消去 |
| 高 | サービス停止 | ファームウェアのバグで冗長ロードバランサが全部ダウン |
| 中 | 機能縮退 | ブログサービス等でIE6で書き込んだときだけ一部文字化けする |
| 低 | 隠蔽 | syslog見るとなんか警告でてる |
今現在は「低」レベルの障害でも、将来的に「高」になりうるのであれば、「高」扱いとします。(例えばメモリリークなど)
こうしておけば、「最高」「高」のときは24時間対応、「中」は平日対応、「低」は手が空いたら対応、のような分類がやりやすくなります。
今までは報告者のフィーリングで高とか中とかつけていたのですが、こうして明確な基準を設けた方が技術屋もマネージャも喜ぶようです。
