Tracで実現するアジャイルオペレーション〜⻘雲編〜

yuzorock

タイトルは釣りです

■お前、誰なん？(広島弁)Twitter:@yuzorock

お仕事：インターネットポータルサイトのサーバエンジニア⼜はオペレーションエンジニア※

※すいません、最近流⾏ってたんで

やってること：サーバを用意したり管理したり運用したり

神器：puppet,kvm,kickstart,ganglia,nagios,excel

プログラム：書けません、読めません

■モチベーション(動機)・Opsのまとめ役として運用の設計から導⼊して廻すところまでをやっている。・OSインストールやユーザ作成、監視設定等、所謂オーダ処理を複数⼈のチームで処理している。・OpsとDevのやり取りはオーダ毎のフォーマットを決めてメールでやり取りをしていた。・メールだと管理がしにくいのでチケット管理システム的なものを探していた。・それで、OpsチームはTracを導⼊してOpsチームだけでそれを使ってオーダ管理をしていた。Devとは従来通りメール。

↓Tracを使いこなすことによって、もっと効率的な運用ができるのではないか。→DevOpsの実現。

■既に綻び始めていた世界(課題)・Devが依頼したオーダの進捗状況がDevから⾒えない。・wikiにオーダの出し⽅とフォーマットが書いてあるから100回熟読してから依頼するようにの世界。・Opsのメンバーはあまり変わらないけど、Devの担当者はよく変わり、チーム内で⽅式の継承も⾏われない。担当者の習熟度に違いが出る。・依頼を出すDevのチームが複数に増えてきた。・個別に相談、あの⼈に御願いしなきゃの属⼈的な世界。・メーラーの検索機能（性能）が重要な世界。

↓こんなの絶対おかしいよ

■僕たちが夢⾒た世界(理想)・定型的なオーダについては全て1ヶ所で管理され、関係者はその進捗状況をいつでも確認できるべき。・定型的なオーダについては誰もが分かりやすく簡単に発⾏でき、最⼩限の⼿間でミスなく処理されるべき。・オーダ処理の流れ及び⼿順はOps側の処理も含め公開され、標準作業時間についてDevに共有されるべき。・DevとOpsのコミュニケーションは1ヶ所で⾏われるべき。

↓アジャイルデベロップメントを⽀えるアジャイルオペレーションの実現

■オーダ管理システムに求められる機能・オーダのチケット管理、ワークフロー管理が出来る・オーダ種別毎に異なる項目の情報を管理できる

※ユーザ作成と故障対応だと管理したい情報の項目が違う・オーダ種別毎に異なるワークフロー(実施フロー)を設定することができる※ユーザ作成と故障対応だとワークフローが違う・オーダの進捗状況及び誰がボールを持っているかについて

WebUIで確認できる。↓

それTracのチケット管理で出来そうだよ

■参考書籍⼊門Trac with Subversion―Linux/Windows対応(著)⾼⼭ 恭介http://www.amazon.co.jp/⼊門Trac-Subversion―Linux-Windows対応-⾼⼭-恭介/dp/4798019615

Trac⼊門 ――ソフトウェア開発・プロジェクト管理活用ガイド(著)菅野 裕、今⽥ 忠博、近藤 正裕、杉本 琢磨http://www.amazon.co.jp/Trac⼊門-――ソフトウェア開発・プロジェクト管理活用ガイド-菅野-裕/dp/4774136158/ref=pd_cp_b_0

■Tracでやろうとした時に問題になること・元々ソフトウェア開発(におけるバグ管理等)で使われるもののため、運用のオーダ管理で使われることを想定した作り(設計・アーキテクチャ)になっていない。⽣まれが違う。・具体的に⾔うと、チケットが管理できる(持てる)情報の項目があらかじめ決まっている。・全てのチケットは標準で用意された同じワークフローを使うことになる。

↓カスタマイズやプラグインで対応可能

■でも難しいんでしょ？Tracに抱いていた誤解・豊富なプラグインがあって、やろうと思えばカスタマイズすることで実現できるんだろうけど、どこかに⼿を⼊れると連鎖的に⾊んなところに不整合が出て使いものにならなくなるんじゃないか？

↓今の所の感想はそんなことない

確かにカスタマイズでゴリゴリ設定しないといけない部分はあるが、それで幹となる部分が壊れるようにはなっていない

↓Tracさんの懐は海より深いでホンマ

■Tracのチケットの説明・⼀枚のticketテーブル(DB)があって、そのテーブルにカスタムフィールドとしてカラム(フィールド)を追加するイメージ。ticket_changeテーブルとかとリレーショナルが張られているようだが自分はあまり気にしていない。(触ることはないと思っている。)

・この後、カスタマイズやプラグインの話になるが、それらの機能を⾒ると、このフィールドの内、type(分類)が重要だと考えている。

・・・・severitystatustypeid

・・・

■Tracのチケットの説明(画⾯)

■Tracのチケットの説明(type)・Tracは元々、ソフトウェア開発やバグ開発管理に使われていたので、それ用に適したフィールド構成になっている。・なので、チケットのtypeもデフォルトで以下のものが用意されている。

defect(故障)enhancement(拡張)task(タスク)

・運用で使う場合には、このtypeフィールドを運用に適したものに変更する。・オーダの種別毎にワークフローを変更するため、オーダ種別の数だけ、typeを作成する。

■Tracのワークフローの説明・ワークフローについても、ソフトウェア開発やバグ管理に適したものとなっており、基本的には全てのチケットが同じワークフローを辿る(使う)ことになる。・デフォルトでは新規作成されたチケットはassignやaccept等のアクション(action)を選択することにより、assignedやaccepted等の状態(status)に遷移しながら、最終的にresolveされclosedになる。・運用で使う場合には、オーダの種別毎に独⽴したワークフローを作成し、そのワークフローを遷移しながらオーダは完了される。

■やらないといけないこと●必須・オーダ種別の洗い出し・カスタムフィールドの追加、タイプ及び項目決め・オーダ種類別ワークフローの作成・オーダ別wikiの作成・Tracユーザ作成

●より便利に使うために・オーダ種類別テンプレートの作成・オーダ種類別サブミットポリシーの作成・puppetと連携

■オーダ種別の洗い出し・Opsが担当している定型化された業務を洗い出してtypeフィールドに追加していく。・後から追加はできる。オーダ数の多い業務から構築していくと良い。・IniAdminとTracCustomFieldAdminを⼊れると便利。

■カスタムフィールドの追加、タイプ及び項目決め・オーダを管理していく上で必要となる項目をカスタムフィールドとして追加する。・初期に用意されたフィールドを削除することは出来ない。しかし、WebUIに表⽰させないことは出来る。・⽅向性としては、いらないものは表⽰させない、必要なものは追加する。・追加の判断の観点として、フィールドにすると、⼊⼒値をコントロールできたりレポートで検索対象に出来るという利点があるが、逆に柔軟性がなくなるというデメリットがある。・各フィールドはtext,checkbox,select等のタイプを使うことができる。・稼働時間や問題点、改善要望を書くフィールドを追加するといいかも。

■オーダ種類別ワークフローの作成・障害対応

・ユーザ作成

障害検知 Dev認知Devに伝える 対応待ち対応して下さい 俺が直すぜ！ 対応中 完了確認待ち直ったぜ！

には状態を書く ※これはワークフローのstatus。どっちがボール持ってるかで⾊分け

には動作を書く ※これはワークフローのaction。

完了確認したぜ！ クローズこんだけ稼働がかかったぜ！ペンディング今無理ス 対応して下さい

ユーザ作りたい Ops認知ユーザ作って 作成中俺が作るぜ！ できたぜ！ 完了確認待ち 完了確認したぜ！ クローズこんだけ稼働がかかったぜ！※破線はTrac外

オーダ種別毎にこのワークフロー図(状態遷移図)を作成する

■オーダ種類別ワークフローの作成・実際のワークフローの設定には、AdvancedTicketWorkflow

Pluginを使う。・オーダ種類別に異なるワークフローの作成を⾏うためには以下のページのtriageの項を参照する。

http://sourceforge.jp/projects/shibuya-trac/wiki/plugins%2FAdvancedTicketWorkflowPlugin・ポイントとしては、出来るだけ共通化したワークフローを使おうと考えず、オーダ種類別に完全にワークフローを分離した⽅が⾒通しが良くなる。その分、設定を多く書く必要がある。・ワークフローのstatusとactionには⽇本語が使えるので、無理に英語にせずに皆に分かりやすい書き⽅(用語)で書く。

■チケットの属性変更とワークフローの進め⽅

⼿動で属性を変更するか

何れかのアクションを選択する

・Ops側はトレーニングにより習熟することが可能なので、⼿動で属性を変更する運用が可能だが、Dev側は基本的にアクションを選択するだけで細かいことを考えずにオーダを進められるようにしたい。

http://trac.edgewall.org/ticket/10187#no3

■オーダ別wikiの作成・オーダ種類別のwikiページを作成する。

wikiの中⾝－オーダ及びオーダフォーマットの説明－オーダワークフロー図

Trac BlockDiag Pluginを⼊れると便利－オーダ登録テンプレートへのリンク－良くある質問とその回答 ※ドキュメントを育て、問合せ減

■Tracユーザ作成・Dev側の担当者やOps側の担当者を全て登録する。・TracAccountManagerを⼊れると便利。・アカウントと紐づくメールアドレスを登録すると、アカウントを選択することで、そのユーザにメールを⾶ばすことが出来る。・Dev側をまとめたdeveloperとかいうロールを権限グループとして権限の管理で設定しておくと後々便利。・Dev側はどこまで⾏っても個⼈が担当者になるが、Ops側は

Ops側の代表ユーザを1つ作って、そこでDev側からのオーダを受ける形を作る。但し、作業を開始するときはOps側の個⼈が受⼊れて作業を⾏う形を作る。これにより、誰がボールを持っているかが明確になるのと、チームでの運用を⾏うことが可能になる。

■オーダ種類別テンプレートの作成・TracTicketTemplateを⼊れて、オーダ種別毎に異なるテンプレートを設定する。これにより、オーダ記載の稼動量の削減とオーダの誤記⼊をある程度無くすことが出来る。・併せて、newticket?で値を渡す、Preset Values for New

Ticketsとこのテンプレートの呼び出しをリンクURLとして、オーダ種別毎のwikiに貼っておくと便利。

http://trac-hacks.org/attachment/wiki/TracTicketTemplatePlugin/NewTicketPage-v0.7.png?format=raw

この部分

■オーダ種類別サブミットポリシーの作成・オーダ種別毎に管理する必要があるフィールドは異なり、必要ないフィールドについては表⽰されなかったり、⼊⼒が出来なかったりした⽅がオペミスがなくなる。・TicketSubmitPolicyを⼊れることで、ポリシー毎に、各フィールドを非表⽰、⼊⼒禁⽌、必須チェックに設定できる。・ポリシーには全てのフィールドとその値を設定できるのが、

type毎に設定すると分かりやすいと思う。・併せてログインユーザや担当者等のアカウント系はグループも設定できるので、Dev側にはこの項目は触らせないといった制御も可能。・詳しい説明はこちらをどうぞhttp://en.sourceforge.jp/projects/shibuya-trac/wiki/plugins%2FTicketSubmitPolicyPlugin

■puppetと連携・ユーザ作成や各種ファイル管理にpuppetを使っている。・puppetのマニフェストはsubversionでバージョン管理されていて、コミット時に今回の変更情報(最新のリビジョンと1個前のリビジョンとのdiffとTrac上のリポジトリブラウザのリンク)がメールで⾶ぶようになっている。・このコミットログにその変更が該当するチケットのリンクを⼊れることにより、チケットとリポジトリのチェンジセットを相互に連携させることが出来る。・Dev側もそれを⾒ることで、自分が依頼したオーダと実際の変更箇所の確認を⾏うことが出来る。

■謝辞・これらの運用を考え、それをTracに落とし込むにあたって、⾊々な⽅から助けて頂きました。・@kanu_さん

twitterでこんなことがやりたいとつぶやいたら、このプラグインで出来るよとか、このプラグインで出来ると思うから翻訳したよとか、完全にこちらの意図を分かった上で的確なアドバイスを頂きました。・@tk0miyaさん @wonderful_pandaさん

Tracでblockdiagをうまく動かせなかったのを助けて頂き、動くようになりました。blockdiag最⾼！！・皆様のおかげで、⻑年やりたかったことをいい形で実現できそうです。ありがとうございます。

■最後に・俺達のTrac道はまだ始まったばかりだ！

・アジャイルについては全く触れられていませんが、これから勉強してアジャイル的な何かをうまく取り⼊れていきたいと思います。

・DevOpsについては、自分はDevとOpsのコミュニケーションのインタフェースの問題だと捉えていて、このようにDevとOpsの間で中⽴的な存在としてその間をつなぐ仕組みがあれば、うまくいくのではないかと考えています。

yuzorock先⽣の次回作“やってみた〜⽴志編〜”にご期待下さい！！