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