チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化
DESCRIPTION
chefでの設定管理などサーバへの操作は自動化が進んでいる。 しかし、チケット駆動によるシステム障害時や作業依頼の案件管理における事務的な作業は人の手により実施されている部分が多く、自動化が必要となる。 そこで特にサーバ/インフラ作業に注目し、そのシームレスな運用を実現するため、担当者の手配、サーバ状態の確認や手順書の準備、実作業までの流れにおける問題点とそれらの自動化を実現するシステムについて述べる。TRANSCRIPT
チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化
Aug/24/2014
Masato Igeta
Global Operations Department, Rakuten Inc.
2
Agenda
1
2
背景
問題点
3
4
5
6
7
目的
提案と実装
期待される効果
今後の課題
まとめ
背景
組織、業務内容、Jira化施策、インフラの流れ
4
背景1 – 組織
• 組織(自部署はインフラ運用部署)
• 自部署担当サービス – Infoseek、楽天オークションなど数十サービス
– 市場やトラベル等は別の運用グループが存在
• 規模感 – サーバ1000クラスタ(開発, 検証, 本番)、2300台程度
– ドメイン数:400弱
• チームのミッション – 根本的な流れを変えるよりその流れにいかに乗るかがテーマ
事業部 APP SYS(ここ) 基盤(NW、監視、Iaas…)
5
背景2 – 業務内容
• 主な業務は依頼作業とアラート対応
–
–依頼窓口が存在しタスクは チケット管理
– SYS作業者がアサインされて実施
• サーバに対して作業だけが業務ではない
–依頼元の要望から具体的な作業を確定
– ドキュメントは で管理
依頼 / アラート 手順書等準備 作業
6
背景3 – Jira化施策
• アラートをJira管理
–休日/夜間に発生したが翌営業日対応を対象
–アラートメールを集計し、Jiraでチケットを起票
–自動で担当者に割り当て
• レビュー、共有をJiraで
– メッセンジャー or メールを削減
–確認したかどうかをステータス管理
監視システム
アラートメール メールサーバ
アラート収集
バッチサーバ
Cron実行
7
背景4 – インフラの流れ
• chefで構成をコード化
– infrastructure as code
–構成をDSLで明記
• DSL:ドメイン固有言語
–作業の自動化
–暗黙知をなくす
# nginxをインストール
package "nginx" do
action :install
end
# nginxを起動しサービスを有効
service "nginx" do
action [ :enable, :start ]
end
要望 DSLを記述 サーバ状態を
DSLの状態に
問題点
完全自動化は困難、作業前業務が多い
9
問題点1-1 – 完全自動化は困難
• 組織の細分化が障壁に
–依頼元、関係部署は別部署
• 社内標準、他部署承認
–調整コスト、ワークフローが膨大
• 現状
–人が間に入って調整
–開発部全体としての改善を進める必要
10
問題点1-2 – 完全自動化は困難
• インフラの完全なコード(chef)化は困難
–すでに秘伝のタレ化
–今までは手作業で作業
–外から買ったりで各クラスタで設定が多種多様
• 現状
–運用じゃなくて構築が現実的(実施中)
–一部固有作業等のツール化(アカウント作成等)
11
問題点2-1 – 作業前業務が多い
• 依頼例:webサーバに新サブドメインを追加
–作業:DNS登録、監視登録、apache設定作業等
–他部署連携多数
• ドメイン承認、DNS作業承認、監視設定ツール
• 社内ツール用ドメインなら連携用設定依頼
• チケットの粒度と完了条件が不明瞭
–実際の要望、サーバの状態? 申請いる? 標準?
–事前のタスク洗い出しが必要
12
問題点2-2 – 作業前業務が多い
• ナレッジマネジメントが充実していない
–運用ルール、手順書等が簡単に纏まっている程度
–具体的に何をすればいいか判断が困難な場合も
• 過去の依頼参考に経験でカバー
–業務の暗黙知化
• ドキュメントが存在すればいいわけでもない
–最新か?、形式が不明瞭(メモ書きレベル)
目的
作業前業務が多い問題に注目し、業務コスト削減と安心を
14
目的 – 業務コスト削減と安心を
• 作業前の「何をすればいいか(準備)」を仕組み化
– 実際の作業は1サーバなら数分で対象は数台程度
– 作業の自動化は基盤グループに
• プル型ではなくプッシュ型で通知
– 情報がどこあるかが自律的にまとまる仕組みが必要
– チームとして得た経験値をチームとして享受
作業前業務をスムーズに実施するためのナレッジマネジメントを
提案と実装
暗黙知なサーバ作業前業務をチケット化
16
提案と実装1 –作業前業務のDSLと実行系
• DSLとして作業前業務をコード化
– Chefのようにコード化して暗黙知をなくす
–内容はTODO、手順書、コマンド結果、特殊仕様
–粒度は他部署インフラエンジニアがわかる水準
• DSLを依頼Jiraにサブチケット化
– Jiraにすれにある作業前ノウハウを添付
依頼
DSL
(過去知見から
事前作成)
作業前業務 サーバ作業
17
提案と実装2 –作業前業務のDSLと実行系
• yamlでタスク記載
– リンク先stash(社内github)上に内容記載
• 添付されたJira上サブタスク
mount:
component: "SVR_MOUNT"
sub_tasks:
todo: https://stash/hoge1
operation_sheet: https://stash/hoge2
command : https://stash/hoge3
specific_info: https://stash/hoge4
*check showmount
*do develop, staging env
*check by APP
*do production env
*check by APP
[dev,stg]
https://stash/ope_sheet/
mount_dev_stg.sh
[pro]
https://stash/ope_sheet/
mount.sh
18
提案と実装3 –作業前業務のDSLと実行系
• 実装
– Python製バッチ、Jira API
–依頼Jiraを定期クローリング
–作業前タスクは各カテゴリごと付与
バッチサーバ
Cron実行
未クロールチケット一覧を取得
依頼カテゴリごとyamlからサブチケット付与
コンテンツはstashから取得
期待される効果
効果は測定中
20
期待される効果
• プッシュ型の利点
–資料を探すコストを軽減
–正しい資料がどれか明白に(更新対象確認も)
–社内標準の担保
• ドキュメントの可読性、保守性向上
– DSL化で予め情報の形式が予測可能
–足りなければドキュメントを足すべきと判断可能
– ドキュメントの目的が明確化
今後の課題
提案手法の継続、依頼・作業・アラート対応での改善
22
今後の課題1 – 提案手法の継続性
• 実際の業務コスト減をモニタリング
• DSLの最適化
– DSLの文法/内容をチームに合わせて最適化
–既存資料へのアクセスログ解析
–チームメンバーへヒアリング
• DSLのメンテナンス継続性を確保
– メンテナンスルールを定義
–更新を評価
23
今後の課題2 – 作業の改善
• 作業完全自動化が可能になった場合
–本提案のDSLから上記ツールへのDSL生成
– ヒューマンループが必要な箇所を洗い出す
• 既存作業を可能な依頼種類は自動化
–アカウント作成等はすでに実施
–少しずつコード化された世界へ
24
今後の課題3 – 依頼の改善
• 依頼フォームUIの改善
–サーバ名等の入力サポート
–設定変更の場合は現状設定を表示
• 依頼項目の最適化
–過去依頼から追加確認項目を列挙
–現状カバーできていない確認事項を洗い出し
25
今後の課題4 – アラート対応の改善
• リアルタイムアラート対応
– Hipchat(メッセンジャー)連携
– Asterisk(電話)連携
– Jiraでもチケット発行
–自動で関係部署へ連絡
–対応手順も自動付与
まとめ
27
まとめ
• 背景 – インフラでのチケット駆動運用を実施中
– サーバ作業前業務が多い
• 目的と提案 – 作業前の業務コストの軽減サポートを目的
– 作業前の業務をDSLとして明文化
– Jiraにそれをサブタスクとして付与し作業者が実行
• 今後 – 効果測定と継続性を高めるための施策が必要
– 依頼や作業段階でも自動化を推進