「チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化」の資料のリンク

インフラ運用チームにおけるチケット駆動の運用について、良い資料があったのでメモ。

【参考】

チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化 from Mst Igt

会社でのJiraについての取り組みを夏のプログラミングシンポジウム2014というとこで話すことになったので資料うp。#sprosym2014 チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化 http://www.slideshare.net/masatoigeta/2014-igeta

インフラ運用チームのタスク管理は、プログラマ主体の開発チームのタスク管理とは異なる。
「主な業務は依頼作業とアラート対応」の通り、顧客やベンダーやアプリチームからの作業依頼、本番障害などの対応が多い。
つまり、突発的な作業で、緊急度の高い作業が結構多い。
すると、JiraやRedmineのようなチケット管理ツールがなければ、突然発生するタスクが割り込んで、日々の作業に追われるだけだろう。

上記の資料で興味深い点はいくつかある。

基本は、手作業の自動化を目指したものの、完全な自動化は無理だったこと。
アラートメールの集計処理の自動化、依頼作業やアラートメールをチケット化など、色々やっている。

しかし、インフラチームの対応先は、顧客、アプリチーム、ベンダー、社内部署など多岐にわたり、組織間の調整がかなり面倒。
チケット化しようにも、外部の利害関係者にチケット更新を強制するのは難しい。

また、暗黙知化したサーバー設定を紐解くのも難しい。
最近のサーバー設定なら、ChefやらDockerなどいろんなツールで再現可能な環境構築が可能だろうが、10年以上前のサーバーが稼働中の場合、そのサーバーの内容をリバースして洗い出すのは非現実的だろう。

そんな問題点を抱えながらも「作業前業務が多い」点に注目して、「作業前業務のDSL化」という対策を実行したのは興味深い。
DSLの内容は具体的に書かれていないが、「作業前業務をコード化」「Chefでやっていたことを人に当てはめる」「DSLとして業務タスクを明文化」「TODO、手順書、特殊仕様、確認コマンド結果をチケット化」という内容から類推すると、手順化できる業務をDLS化したみたい。
おそらく、Rakeもしくはyamlで手順をDSL化し、DSLをチケットに添付して運用担当者に作業を依頼し、DSLの実行結果をログとして残す運用と思われる。

DSLを使う発想はそもそもどこから出てきたのか、すごく興味はある。
おそらく、Chefなどを触っているうちに、手順化できる業務はRakeなどにまとめられると気付いて、DSL化する発想にたどり着いたのではないか？

そういう意味では、Rubyの強力なメタプログラミング機能が、手順や業務を抽象化して再利用できる方向に使えることを示唆しているように思える。

【追記】
感想があったのでメモ。

akipiiさんはTwitterを使っています: "大変参考になりました。RT @noexpect: いろいろ書いていただけててありがたい。 「チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化」の資料のリンク http://t.co/UpULRDC5rP"