新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた
•Download as PPTX, PDF•
15 likes•21,403 views
【明日の開発カンファレンス 2018】 方眼紙Excelのサーバ変更手順書、実機と設定値が異なるパラメーターシートがはびこるプロジェクトを、開発・保守・運用チームまで巻き込み、変革した話です。 周りはGit??CI??なおじさんたちばかり。そして、エンプラ&オンプレというInfrastructure as Codeと相性の悪い領域。泥臭く、根気よく、最後まであきらめずに、導入を進めてきました。 "先進的なツール"と"今までのやり方や文化"をうまく結びつけるために、どのような工夫をしたかをお伝えします。
More Related Content
What's hot
What's hot (20)
Similar to 新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた
Similar to 新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた (20)
More from Shuntaro Saiba
Recently uploaded
Recently uploaded (15)
新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた
- 1. 新卒3年目のぼくが、でぶおぷす???な オジサンだらけの エンプラ金融PJ にAnsibleを導入してみた Future Architect, Inc. Shuntaro Saiba 明日の開発カンファレンス 2018
- 4. 補足: Ansibleとは 3 管理サーバ 対象サーバ ・・・etc. サービス起動・停止 設定ファイル書き換え パッケージインストール ファイルデプロイ Ansibleで自動化 x N台 x N台 x N台 オープンソースなサーバ管理ツールです
- 5. 補足: Ansibleとは 4 Infrastructure as Code のツールです 手作業が多く発生 手順書&スクリプトの構成管理が困難 従来 Infrastructure as Code 手順書 手作業 & x N台 x N台 x N台 ソースコード & x N台 x N台 x N台 自動化ツール 作業の省人化と効率化によるコスト削減 オペレーションミスの発生可能性を低減 手順書のコード化による高度な品質保証
- 6. 補足: おじさんとは 5 いろいろ知らない & 使いたがらない 人を指します
- 7. 6
- 9. 自己紹介 8 齋場 俊太朗 (さいば しゅんたろう) インフラ ~ CI回り担当 (新卒4年目) Future Architect, Inc. Technology Innovation Group所属 Qiita 記事 “EC2上にHoneypot(T-Pot)をインストールして サイバー攻撃をELKで可視化してみた。” @tarosaiba
- 10. 自己紹介 9 2015年 新卒入社 今 現在 エンプラ小売り & AWS エンプラ金融 & オンプレ エンプラ小売り & GCP 新人で配属されたPJ インフラ&CIを担当 クラウドの魅力を知る その反面サーバ管理のツラミも知る 3年目で配属 オンプレについても知りたく希望 Ansible導入を推進 今現在のPJ GCP & Kubernetesに苦戦中 まさに、夢のような世界
- 11. 自己紹介 10 新人で配属されたPJ インフラ&CIを担当 クラウドの魅力を知る その反面サーバ管理のツラミも知る 3年目で配属 オンプレについても知りたく希望 Ansible導入を推進 今現在のPJ GCP & Kubernetesに苦戦中 まさに、夢のような世界 2015年 新卒入社 今 現在 エンプラ小売り & AWS エンプラ金融 & オンプレ エンプラ小売り & GCP
- 12. 話の経緯 11 金融系プロジェクトの基盤更改にアサイン(昨年4月~12月) – はじめは、サーバ&NWの下っ端として バリバリのエンプラ系 – なかなかお堅いです。もちろんオンプレ 問題あり。現行のサーバはまさに、ブラックボックス – Excelの設計書はもはや意味なし。「それ、信じちゃだめだからね」byボス サーバ台数 ≒ 150台 (複数環境合わせて) – それぞれのサーバが5年間の手作業によって育ってきちゃっている
- 15. 今できていること 14 MW設定 ベンダ-構築 サーバ構成要素 その他の構成要素 パッケージ管理 OSユーザグループ ディレクトリ作成 ファイル 構築 - MW ログ その他 ベンダ構築 - MW MW 個人ユーザ 全て NW設定 ディスク設定 ssh設定 cron設定 カーネル設定 構築 その他 ：ソースコード化済み
- 16. 今できていること 15
- 24. 23 そして、、
- 25. 24 これ
- 26. 25 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば
- 27. 26 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば コマンドが改行されてる！！(怒ﾟДﾟ)ﾉ 変な文字混じってる！！(怒ﾟДﾟ)ﾉvimなの！！(怒ﾟДﾟ)ﾉ ここでdiffの確認！？(怒ﾟДﾟ)ﾉ 2号機..N号機！！(死ﾟДﾟ)ﾉ 方眼紙！！ (怒ﾟДﾟ)ﾉ ネ申 Excel手順書
- 28. 27 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば コマンドが改行されてる！！(怒ﾟДﾟ)ﾉ 変な文字混じってる！！(怒ﾟДﾟ)ﾉvimなの！！(怒ﾟДﾟ)ﾉ ここでdiffの確認！？(怒ﾟДﾟ)ﾉ 2号機..N号機！！(死ﾟДﾟ)ﾉ 方眼紙！！ (怒ﾟДﾟ)ﾉ
- 30. 29 前置きが長くなりましたが
- 32. Ansible導入するまでの話 31 リーダー陣 アプリ インフラ 運用 : 偉い 保守 私 はじまり インフラ&アプリチームへ プロジェクトリーダー陣へ 運用チームへ 保守チームへ まとめ&さいごに 1 2 3 4 5 6 1 2 3 4 5 6
- 33. 32 自動化 技術 ツール
- 36. 35 1. はじまり 1 2 3 4 5 6
- 37. 話の経緯 ※再掲 36 金融系プロジェクトの基盤更改にアサイン(昨年4月~12月) – はじめは、サーバ&NWの下っ端として バリバリのエンプラ系 – なかなかお堅いです。もちろんオンプレ 問題あり。現行のサーバはまさに、ブラックボックス – Excelの設計書はもはや意味なし。「それ、信じちゃだめだからね」byボス サーバ台数 ≒ 150台 (複数環境合わせて) – それぞれのサーバが5年間の手作業によって育ってきちゃっている 1 2 3 4 5 6
- 38. 37 「 サーバ構築は“元気玉”で 」 っえ？.. ※元気玉: メンバーみんなで手分けして、(手作業で)頑張ろうということ ボス わたし 1 2 3 4 5 6
- 39. 昔の記憶が、よみがえりました。。
- 40. 39 構築作業を自動化できていなかったあの時代.. 1 2 3 4 5 6
- 42. 41 サーバの構成管理をできていなかったあの時代.. 1 2 3 4 5 6
- 44. 43 サーバ管理で苦しむのは もう、いやだーーーー！ 1 2 3 4 5 6
- 45. 44 サーバ管理で苦しむのは もういやだーーーー！ そこで Ansible を導入しようと 考えました 1 2 3 4 5 6
- 46. インフラチームボスへ提案してみた 45 Infrastructure as Codeについての説明資料は自前で – DevOpsとかの言葉は通じない.. Gitも初なのでレベルを合わせて 初めは????だけど、実際に動くものを見せたらいい感じだった エージェントレス & Redhatブランド は大きな後ろ盾になった 1 2 3 4 5 6
- 47. インフラチームボスへ提案してみた 46 説明資料 yamlファイル DEMO ボスわたし 1 2 3 4 5 6 こんなことができます ほーちょっとやってみてよ
- 48. インフラチームボスへ提案してみた 47 説明資料 yamlファイル DEMO ボスわたし 1 2 3 4 5 6 こんなことができます ほーちょっとやってみてよ Ansible導入が始まりました
- 49. 48 2. インフラ&アプリチーム まずは身近なところを仲間にしよう 1 2 3 4 5 6
- 50. 大切にしたポイント 49 • スモールスタートで拒絶反応をなくす • 仕組みを先に作ってしまう 1 2 3 4 5 6
- 51. 小さい範囲からAnsibleで自動化 50 まずは、サーバへの設定ファイル配布に絞ってAnsibleを使い始めた – いきなり全てソースコード化するのはハードルが高い&拒否される可能性大と 考えた – はじめは、hosts, resolv.conf のOS設定ファイル..等の配布にAnsibleを利用 1 2 3 4 5 6
- 52. 51 小さい範囲からAnsibleで自動化 設定ファイル hosts roles/ etc/web-svr.yml db-svr.yml xxx-svr.yml db-svr/ xxx-svr/ tasks/web-svr/ deploy.yml files/ hosts resolv.conf 構成 1 2 3 4 5 6 はじめ使用したのは Ansible copy module 配布用ファイル
- 53. Ansibleファンを増やしていく 52 垣根なくチームの要望に聞き耳を立てて、Ansibleでどんどんこなす！！ – NW : NW機器のconfigの構成管理したいな.. – 基盤 : ifconfigの実行結果全部取集したいな..このpkg全台に導入してほしいな.. – APP：設定ファイル勝手に変更されてAPP動かなくなってる.. 構成管理したいな.. – 他にも： Windowsに対しても作業自動化したいな.. 1 2 3 4 5 6
- 54. 53 Ansibleファンを増やしていく アプリの人 NW機器も Windowsも NWの人 わたし 1 2 3 4 5 6 要望をヒアリング どんどんAnsibleでこなす
- 55. “みんなが”使える仕組みを先に整える 54 AnsibleソースをExcel一覧から自動生成できるようにした – fileデプロイ、dir作成、user&group作成 けっこう簡単 (ymlの恩恵) – サーバ変更依頼は、Excelインターフェースで受けるようなフローに Ansibleソース変更&実行フローはどんどん自動化 – “ Ansibleソース生成 → デプロイ → サーバへ適用 ” with Jenkins 1 2 3 4 5 6
- 56. 55 みんな使えるような仕組みを整えた話 1 2 3 4 5 6 Excel ファイル - name: Add user user-hoge user: name: user-hoge uid: 1001 group: unyo home: /home/user-hoge shell: /bin/bash password: “xxxxxxxx" state: present - name: Add user user-fuga user: name: user-fuga uid: 1002 group: unyo home: /home/user-fuga shell: /bin/bash password: “yyyyyyyy" state: present [..] Ansibleファイル Name uid group home shell password State user-hoge 1001 admin /home/user-hoge /bin/bash xxxxxxxx present user-fuga 1002 admin /home/user-fuga /bin/bash yyyyyyyy present ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ Pyhonスクリプト Jenkins & 使いたい人 みんな大好きExcelを使って yamlファイルの自動生成
- 57. 使わざる負えない仕組みを先に整える 56 ソースコードとの差分(手動変更)は自動検知&フィードバック可能にした – Ansibleの仕組み以外(手動)でサーバへ変更が発生する (絶対誰かがやる) – やっぱり(先輩とかだと)、自分からは注意し辛い – 不整合一覧をチーム全体に共有して、ボスから指示いただくフローに 1 2 3 4 5 6
- 58. 57 使わざる負えない仕組みを先に整える ソースと突合 フィードバック情報(file)を収集 ボス わたし 1 2 3 4 5 6 手でいじらないように！ 手でサーバ葬っちゃう人には ボスからのフィードバックを 変更作業 (手動)
- 59. PJメンバー 58 リーダー陣 アプリ インフラ 運用 : 偉い 保守 Ansible いいね！！ 1 2 3 4 5 6
- 60. PJメンバー 59 リーダー陣 アプリ インフラ : 偉い 運用 保守 1 2 3 4 5 6
- 61. 60 DevOps !?!? 1 2 3 4 5 6
- 63. 大切にしたポイント 62 • 今までの(インフラ)課題と結びつける • ビジョンを掲げる 1 2 3 4 5 6
- 64. 今までの課題の解決法として提案 63 過去のインフラ課題(チケット)を探り出し、解決案としての提案を行った – インフラの不備による障害は、リーダー陣としても課題意識が大きかった – 特に、STG環境と本番環境の意図しない差異による障害について – 構成管理&構築自動化が私のスコープだったが、環境間不備のチェックも行えると アピール 1 2 3 4 5 6
- 65. 64 今までの課題の解決法として提案 課題 内容 Infrastructure as Codeを導入した場合 • インフラ(OS,MW, NW) 設定をソースコードとして 正確な構成管理が可能になる • ソースコードに定義した設定と実機の設定を比較することにより 環境の不整合を検知可能 構成管理 • アプリのソースコードはバージョン管理ができているが インフラ(OS,MW, NW)に関しては、バージョン管理が正確に できていない • 構築&設定変更作業の自動化が可能になり、 ヒューマンエラーを防ぐことができる ヒューマンエラー • サーバへの設定変更の大半は、手作業によって行われている • 各環境の環境設定の差分を ソースコードの差分として把握、管理することが可能 • あるべき差分を管理することで意図しない環境間差分を検知可能 環境間差異 • 各環境の環境設定の差分を正確に管理できていない 1 2 3 4 5 6
- 66. ビジョンを掲げて提案 65 Ansibleとは何か？ではなく、Ansibleを導入してどう変わるのかを提案 – リーダ人にっては、”いんふらすとらくちゃーあずこーど” なにそれおいしいの？ – 細かく説明するのではなく、概念レベルで説明 (絵にしたのが効果的) 1 2 3 4 5 6
- 67. 66 ビジョンを掲げて提案 PRD STG DEV ソースコードの自動適用 ソースコードとの自動突合 ソースコミット バージョン管理ツール PRD STG DEV 手作業での変更は 原則禁止 環境 インフラ作業者 ソースコードの履歴管理 環境差異の突合 1 2 3 4 5 6 Ansibleで実現できることをアピール
- 69. 68 4. 運用チーム 実際に作業をする人たちに使ってもらって 便利さをわかってもらおう 1 2 3 4 5 6
- 71. 簡単なことから作業改善を提案 70 運用チームが日々行う作業に対して、Ansibleでの効率化を提案 – インフラのソースコード化は難しくても、Ansibleコマンド実行でも役に立つこと沢山 – いままで、1台1台サーバにsshしていた作業を自動化 – まずは、Ansibleの便利さを知ってもらうことを目標に 1 2 3 4 5 6
- 72. 簡単なことから作業改善を提案 71 コマンド発行 OK! ファイル回収 OK! NW config回収 OK! ただAnsibleコマンド(ラップシェル)実行すればOK!! Ansible コマンド利用 fetchモジュール 利用 ciscoモジュール 利用 任意のコマンド 任意のファイル NW config 1 2 3 4 5 6
- 73. 手順書＆ラップスクリプトを整備 72 誰でも便利に使えるように手順書&ラップスクリプトを作成 – PlaybookとかRoleという概念はいきなりハードル高い – コマンド粒度の手順書レベルまで落とし込めば、全然使ってもらえた 1 2 3 4 5 6
- 74. 手順書＆ラップスクリプトを整備 73 1 2 3 4 5 6
- 75. 手順書＆ラップスクリプトを整備 74 1 2 3 4 5 6 とにかく書きまくりました
- 77. 76 5. 保守チーム Ansibleでのサーバ管理方法を うまく回していってもらおう 1 2 3 4 5 6
- 79. “いっしょに”ワークフローを検討 78 現状のリリースフローをヒアリングしてしっかりすり合わせする – 今までのSVNのリリースフローとGitフローで整合性を保つ必要があった – リーダ承認のフローもGitのMRフローとして採用してもらうように 1 2 3 4 5 6
- 80. 一緒に作り上げたワークフロー 79 1 2 3 4 5 6
- 81. 今までのやり方と調和するよう提案 80 ネ申Excel手順書を根絶するのではなく、調和させるようにする – 根本から作業フローを変えるのは難しい – ベースのやり方はそのままで、Ansible実行方法をいっしょに考える 1 2 3 4 5 6
- 82. 今までのやり方と調和するよう提案 81 1 2 3 4 5 6
- 83. 今までのセキュリティポリシーは守る 82 Ansibleの導入によりセキュリティレベルが下がらないようにする – rootパスワードや鍵の管理は従来の方法を実現できるように実装する – 開発→本番環境 へのNW遮断 もファイル連携でひと手間加えて 1 2 3 4 5 6
- 84. 今までのセキュリティポリシーは守る 83 踏み台(Ansible) サーバ 作業対象サーバ rootパスワード 手入力 運用メンバー 踏み台(Ansible) サーバ 作業対象サーバ 本番環境開発環境 運用メンバー Ansible ソース ファイル連携 パスワード管理 OK! NW経路 OK! 1 2 3 4 5 6
- 86. 85 そして、ついに..
- 87. 86 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば コマンドが改行されてる！！(怒ﾟДﾟ)ﾉ 変な文字混じってる！！(怒ﾟДﾟ)ﾉvimなの！！(怒ﾟДﾟ)ﾉ ここでdiffの確認！？(怒ﾟДﾟ)ﾉ 2号機 N号機！！(死ﾟДﾟ)ﾉ ネ申 Excel手順書 方眼紙！！ (怒ﾟДﾟ)ﾉBEFORE
- 88. 87 NO 項目 コマンド 確認者 1 2 3 さいば 踏み台サーバへログインする ssh user@btn01svr hostname;whoami;pwd → ホストネームを確認する さいば ansible-playbook bat-svr.yml ログアウトする exit Ansibleを実行する さいば これだけ！！嬉゜ω゜）楽 ※ 実際には2,3手順あります AFTER これはもうしょうがない。
- 89. PJ メンバー 88 リーダー陣 アプリ インフラ 運用 : 偉い 保守Ansible いいね！！ by PJメンバー 一同 1 2 3 4 5 6
- 90. 89 さいごに 1 2 3 4 5 6
- 91. 全体を通じて大切にしたポイント 90 • 今までの文化にツールの方を合わせていく • あきらめない 1 2 3 4 5 6
- 92. ベストプラクティスは捨てる 91 Ansibleのベストプラクティスが私たちにベストとは限らない – 今までの考え方に歩み寄りできるようにした – インフラをソースコード化するというプロセスに拒否反応を抱かせないよう、今までの 考え方に親和するようにした 1 2 3 4 5 6
- 93. 92 楽 複雑 手間 分かりやすい おじさんにとって 1 2 3 4 5 6 ベストプラクティスは捨てる
- 94. 93 hosts roles/ サーバ種=role ファイルシステム を再現 Ansibleの構成 web-svr.yml db-svr.yml xxx-svr.yml web-svr/ db-svr/ xxx-svr/ tasks/ files/ etc/ main.yml deploy_files.yml mkdir.yml ansible.cfg usergroup.yml hosts resolv.conf Excelから自動生成 # ファイル配置する定義 webサーバに対して # dirを作成する定義 # usrgroupを作成する定義 # 配布する実ファイル群 “静的”ファイルのみ 1 2 3 4 5 6
- 95. 94 hosts roles/ サーバ種=role ファイルシステム を再現 Ansibleの構成 web-svr.yml db-svr.yml xxx-svr.yml web-svr/ db-svr/ xxx-svr/ tasks/ files/ etc/ main.yml deploy_files.yml mkdir.yml ansible.cfg usergroup.yml hosts resolv.conf Excelから自動生成 # ファイル配置する定義 webサーバに対して # dirを作成する定義 # usrgroupを作成する定義 Ansibleベストプラクティス ガン無視 Orz # 配布する実ファイル群 “静的”ファイルのみ おじさんたちへの分かりやすさを優先 taskファイルの冗長は、自動生成なのでOK 1 2 3 4 5 6
- 96. あきらめない 95
- 97. 分かってもらえるまで説明する 96 ここがコウデ。.. 自動化できます。 1 2 3 4 5 6 ぐぬぬ。。
- 98. 分かってもらえるまで説明する 97 ここがコウデ。.. 自動化できます。 中身の処理は こうなっていて.. 1 2 3 4 5 6 ぐぬぬ。。 ぐぬぬぬ。。
- 99. 分かってもらえるまで説明する 98 ここがコウデ。.. 自動化できます。 中身の処理は こうなっていて.. 実際の定義ファイル はこうなっていて.. 1 2 3 4 5 6 なるほどナー！ ぐぬぬ。。 ぐぬぬぬ。。 やった！
- 100. 分かってもらえるまで説明する 99 1 2 3 4 5 6
- 101. 分かってもらえるまで説明する 100 1 2 3 4 5 6
- 103. 絶対にサーバを手で葬らせない 102 & 1 2 3 4 5 6 サーバ
- 104. 絶対にサーバを手で葬らせない 103 & ディレクトリ 手で作っちゃおうっか 1 2 3 4 5 6 サーバ
- 105. 絶対にサーバを手で葬らせない 104 & サーバへの変更は手で 行わないでください！ 手で変更する場合は 作業内容をメモでください ディレクトリ 手で作っちゃおうっか ※ あとで私がAnsibleソース化する 1 2 3 4 5 6 サーバ
- 106. 絶対にサーバを手で葬らせない 105 & サーバへの変更は手で 行わないでください！ 手で変更する場合は 作業内容をメモでください ディレクトリ 手で作っちゃおうっか ※ あとで私がAnsibleソース化する 1 2 3 4 5 6 サーバ 口うるさい嫌われ役 めちゃ辛い。
- 107. 106 振り返ってみて 1 2 3 4 5 6
- 108. 導入までの歩み 107 2017 5月 2017 12月 2018 2月 ユーザ会で発表夏祭りで発表 2017 8月 検証 実装 改良 導入検討 Dev 運用検討 運用中 Ops Ansibleでの 構築開始 システム リリース 引継ぎ・勉強会 Ansibleでの 運用開始 今 1 2 3 4 5 6 地道な普及活動
- 109. 導入までの歩み 108 2017 5月 2017 12月 2018 2月 ユーザ会で発表夏祭りで発表 2017 8月 検証 実装 改良 導入検討 Dev 運用検討 Ops Ansibleでの 構築開始 システム リリース 引継ぎ・勉強会 Ansibleでの 運用開始 今 私、PJから離脱 1 2 3 4 5 6 地道な普及活動 運用中
- 110. 109 (おまけ) 引継ぎ 私がPJを抜けた後でも、この仕組みを 回す&改善していってもらわねば 1 2 3 4 5 6
- 111. 引き継いだ内容 110 1 2 3 4 5 6 Ansible の使い方 (+CIツール) 自動化の考え方
- 112. 引き継いだ内容 111 1 2 3 4 5 6 今までの文化 これから(理想)の文化
- 113. 引き継いだ内容 112 1 2 3 4 5 6 今までの文化 これから(理想)の文化 変えたい
- 116. 自動化すれば 115 自動化が進めば余剰の時間が生まれ、さらなる自動化を進められる。 ※ あくまでも理想 作業の自動化 コスト削減 手作業がなくなる 余剰の時間が生まれる
- 117. 自動化するかしないか 116 自動化する OR しない どちらかを選択する際の観点 自動化する 自動化しない 自動化するための コスト 運用の変化の 重み 削減できる コスト オペミスの削減 効果 変化しないリスク 変化するリスク
- 118. 自動化するかしないか 117 自動化する OR しない どちらかを選択する際の観点 (私の考え) 自動化するための コスト 運用の変化の 重み 削減できる コスト オペミスの削減 効果 変化しないリスク 変化するリスク 自動化する 自動化しない
- 121. 120 ポイントまとめ プロジェクトリーダへ 今までの(インフラ)課題と結びつける ビジョンを掲げる 運用チームへ 簡単なことで使ってもらって慣れてもらう だれでも使えるように手順書を作りこむ 保守チームへ 考え方を押し付けるのではなく、いっしょに考える 今までのやり方と調和させる 1 2 3 4 5 6 インフラ&アプリチームへ スモールスタートで拒絶反応をなくす みんなが使える仕組みを先に作ってしまう 全体を通じて 今までの文化にツールの方を合わせていく あきらめない
- 122. 121 まとめ&これから DevOpsのツール&考え方と疎遠な人たちに導入するには工夫が必要 – とにかく、分かりやすい&使いやすいを最優先に – おじさんたちには机上では伝わらない、実際に体験してもらう PJ内の各チームは意外にも導入に好意的であった – みんなそれぞれ課題を抱えていて、解決方法を求めていた – みんな、”知らない”&”どうやったらよいかわからない” だけ – チームごとに異なるアピール方法が必要 新しい文化を作っていくのはやっぱり時間が必要 – 5年以上育て来た今までの文化をいきなり捨てるのは無理 – 今も、保守・運用チームにこの仕組みを育てていってもらっているところです – (徐々に入れ替わっていって、Excel手順書がなくなることを祈っています) 1 2 3 4 5 6
- 124. 123 ありがとうございました 1 2 3 4 5 6
- 125. 124 奇人・変人・達人大募集中！ We are hiring engineers!!
Editor's Notes
- -65sec
- -65sec
- -
- -50sec