Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
JANOG48_NW運用自動化の拡大/janog48_nwauto
Search
mito
July 15, 2021
Technology
2
260
JANOG48_NW運用自動化の拡大/janog48_nwauto
mito
July 15, 2021
Tweet
Share
More Decks by mito
See All by mito
クラウドリフトとクラウドシフトで変わる運用/CODT2023
mito201
0
160
クラウドネイティブエンジニアを育成する/CNDT2022
mito201
1
620
Backlogをサポート窓口として活用する/JBUG_Summer_2022
mito201
0
870
sudo_pip_installするときはよく考えて!/sudo_pip_install_ansible
mito201
0
1.1k
VBAで始める手のひらの上の自動化/vba_faile-coordination
mito201
0
1.2k
AnsibleとCloudFormationの組み合わせでトレーニング環境を運用している話/ansible-and-cfn
mito201
2
3.2k
VBAから見たAnsiblePlaybookとの比較/diff-vba-ansible
mito201
0
550
Other Decks in Technology
See All in Technology
30万人の同時アクセスに耐えたい!新サービスの盤石なリリースを支える負荷試験 / SRE Kaigi 2026
genda
4
1.4k
AzureでのIaC - Bicep? Terraform? それ早く言ってよ会議
torumakabe
1
600
Agile Leadership Summit Keynote 2026
m_seki
1
670
モダンUIでフルサーバーレスなAIエージェントをAmplifyとCDKでサクッとデプロイしよう
minorun365
4
220
SRE Enabling戦記 - 急成長する組織にSREを浸透させる戦いの歴史
markie1009
0
170
マネージャー視点で考えるプロダクトエンジニアの評価 / Evaluating Product Engineers from a Manager's Perspective
hiro_torii
0
180
Codex 5.3 と Opus 4.6 にコーポレートサイトを作らせてみた / Codex 5.3 vs Opus 4.6
ama_ch
0
200
AIエージェントを開発しよう!-AgentCore活用の勘所-
yukiogawa
0
190
SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル / SRE Kaigi 2026
aeonpeople
6
2.5k
ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立
rvirus0817
1
1.6k
データの整合性を保ちたいだけなんだ
shoheimitani
8
3.2k
Bedrock PolicyでAmazon Bedrock Guardrails利用を強制してみた
yuu551
0
260
Featured
See All Featured
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
190
GitHub's CSS Performance
jonrohan
1032
470k
Claude Code のすすめ
schroneko
67
210k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.1k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
0
140
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
310
How Software Deployment tools have changed in the past 20 years
geshan
0
32k
Why Our Code Smells
bkeepers
PRO
340
58k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
420
Designing for Timeless Needs
cassininazir
0
130
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3k
Transcript
導入したNW運用自動化を どのように拡大しますか。 開発が担当?運用が担当?それとも? 2021/07/14 伊藤雅人 @mizuto1217
自己紹介 ◼ 氏名:伊藤 雅人 ◼ 経歴:携帯電話の開発(3G時代)から帯域制御装置の保守・技術検証、 製造業の情シスを経て、現所属へ。 現在は、Ansibleを軸としたネットワーク運用自動化案件のPM、 Ansibleトレーニングの講師を担当しています。 2
今日議論したいこと ◼ 以前は、開発寄りの立場としてTera Termマクロ、shell、VBAなどの自作ツールを 作り、NW運用の自動化を提供していました。今は、Ansibleを軸としたミドル ウェアによるNW運用の自動化を提供しています。 ◼ 何らかの作業を自動化し効果を得られると、類似の作業や面倒な作業も自動化で きないか考えると思います。そこで、本日は導入したNW運用の自動化をどう拡 大するか、まずは私の経験をお伝えし、作る側、使う側、または作って使う側、
それぞれの立場からご意見をいただき、良い議論の場になれば幸いです。 ◼ 前提となるツールはAnsibleとなりますが、他の自動化ツールに置き換えて いただいても共通するかと思います。 3
目次 ◼ NW運用自動化の拡大に必要そうなもの ◼ 開発と運用が一体化している話 ◼ 開発と運用が分かれている話 ◼ 開発と運用と自動化推進チームの話 ◼
経験のまとめ ◼ 導入したNW運用の自動化をどう拡大するか 4 私の経験 議論
NW運用自動化の拡大に必要そうなもの
NW運用自動化の拡大に必要そうなもの 6 意思 共通の認識を持っている そうでないと、決定・動きはじめに時間がかかり停滞してしまう 担当 自動化推進チームを作る 自動化を作業の一つとすると、今現在運用できているため停滞してしまう スキル 自動化の推進役(有識者)がいる
有識者がいないとスキルの習得からになる(拡大の前段階) 工数 自動化を行うための工数が確保できている 自動化すると工数削減できるは結果であり、自動化するための工数が必要 私が思う
開発と運用が一体化している話
開発と運用が一体化している話 8 1. 自動化を広げる気はない 2. 開発と運用の距離が近い 3. 開発も運用もプログラミングの知識がある 4. 運用の稼働がひっ迫気味
客先常駐していました
開発と運用が一体化している話 9 ◼ シェルスクリプト、VBA 、Tera Termマクロによる1作業の個別最適化を実施 ⚫ 年300時間の工数削減を達成 ⚫ ツール開発楽しいなー!!
自動化を広げる気はない ◼ 開発にも運用にも自社のメンバーが所属しており、コミュニケーションが とりやすい ⚫ 縦割りだけど、垣根がゆるめ 開発と運用の距離が近い
開発と運用が一体化している話 10 ◼ スキルトランスファーは基本的にしない ◼ 自作ツールの文化がある ⚫ すでに複数の自作ツールを運用している 開発も運用もプログラミングの知識を持っている ◼
工数を削減する自動化を歓迎してくれる ⚫ ヒアリング、説明の時間を取りやすい 運用の稼働がひっ迫気味(とはいえ、
開発と運用が一体化している話 11 ◼ 運用(利用する側)もプログラミング知識があり、受け入れやすい環境だった ◼ 距離が近いので相談しやすい 良かった点 ◼ 個別最適化なので、広がらない ⚫
自動化を拡大する気はなし 難しかった点
開発と運用が分かれている話
開発と運用が分かれている話 13 1. 1作業の個別最適化ではなく、ミドルウェアによる全体最適化を想定 2. 運用が運用業務の1タスクとして自動化を拡大する 3. 運用にAnsibleの有識者はいない 4. 運用の稼働がひっ迫気味
請負でAnsibleによる運用自動化を導入しました
開発と運用が分かれている話 14 ◼ 自動化の余地が多大にある ⚫ 手作業が多く、夜間のダブルチェック作業もある ⚫ 他システムとの連携が図れる 1作業の個別最適化ではなく、ミドルウェアによる全体最適化を想定 ◼
当然といえば当然ですが、既存の運用業務が最優先 ⚫ 自動化の拡大は二の次 運用業務の1タスクとして自動化を拡大する
開発と運用が分かれている話 15 ◼ トラブルシューティングの難易度が高い ⚫ 作成した Playbook は、応用的な内容でボリュームがある ⚫ Ansibleのトレーニングは実施したが、使えるとトラブルシューティングができるは別
運用にAnsibleの有識者はいない ◼ ただでさえ現場の工数を確保しづらいうえに、今後、さらに稼働がひっ迫し ていくことがみえていた(その準備も必要) 運用の稼働がひっ迫気味
開発と運用が分かれている話 16 ◼ ミドルウェアによる全体最適化の導入は、自部署のみならず、他部署にも 自動化の良さを知ってもらえた ⚫ 運用品質向上の施策で一位をとった 良かった点 ◼ スキルトランスファーの工数が確保しづらい
⚫ 初学者がトラブルシューティングを行えるようになるまでの時間はなかった 難しかった点
開発と運用と自動化推進チームの話
開発と運用と自動化推進チームの話 18 1. 自動化を拡大するというミッションを持っている 2. 自動化推進チームを作った 3. すでにAnsibleを使用している 4. 自動化拡大のための工数が確保されている
現在進行形の話で、コンサルに近い立場として関わっています
開発と運用と自動化推進チームの話 19 ◼ 自動化に抵抗がない ◼ 関係者が自動化を強く意識している ⚫ 開発するとしたらどうするか、運用するとしたらどうするかを考えている 自動化を拡大するというミッションを持っている ◼
開発にも運用にもあかるい人たちを集め、自動化推進チームを作った ⚫ 開発が最初から最後まで担当するというわけではなく、かといって、 運用にあとを全て任せるわけではない 自動化推進チームを作った
開発と運用と自動化推進チームの話 20 ◼ Ansible の有識者がおり、他領域の作業を自動化している ⚫ 導入のハードルがとても低い、障壁が少ない ⚫ トラブルシューティングもしている すでにAnsibleを使用している
◼ 物事がスムーズに進みやすい 自動化拡大のための工数が確保されている
開発と運用と自動化推進チームの話 21 ◼ 開発にも運用にもあかるい人たちを集め、自動化推進チームを作った ⚫ 自動化の拡大がミッションなので、工数も確保しやすい ◼ Ansible の有識者がいる ⚫
導入のハードルが低い 良かった点 ◼ 予算の壁 ⚫ 現場と決裁者が考えるゴールは異なる 難しかった点
経験のまとめ
NW運用自動化の拡大に必要そうなもの 23 ◼ 開発にも運用にもあかるい人たちを集め、自動化推進チームを作った ◼ すでに自動化のスキルをもっていた ◼ 自部署のみならず他部署にも自動化の良さが広まった ⚫ 予算の壁を越えやすい
良かったパターン ◼ スキルトランスファーの工数確保が難しい ⚫ いざとなったら手作業で対応できることが、後向きに働くこともある ◼ 使うことはできるが、トラブルシューティングが困難 難しかったパターン さじ加減が難しい 運用から人を引きはがすとどうなるか?
NW運用自動化の拡大に必要そうなもの 24 意思 共通の認識を持っている (協力者が増えて、自動化拡大が加速する) 担当 自動化推進チームを作る (協力者が増えて、自動化拡大が加速する) スキル 自動化の推進役(有識者)がいる
(スキルの底上げがしやすく、自動化拡大が加速する) 工数 自動化を行うための工数が確保できている (自動化を進めやすく、自動化拡大が加速する)
25 導入したNW運用の自動化を どのように拡大するか • 誰がどのように動くと拡大できる? • 拡大するためには何が必要? • ここまでの発表で気になるところ
導入したNW運用の自動化をどのように拡大するか 26 拡大したいか 前提として、自動化を拡大する方針ですが、 そもそも拡大したくない理由はありますか? うまくいっている話 実施して良かったと思うポイント 意志、担当、スキル、工数やそれ以外の切り口について うまくいかない話 難しいと思ったポイント
意志、担当、スキル、工数やそれ以外の切り口について
導入したNW運用の自動化をどのように拡大するか 27 誰が担当する 開発(作る側)と運用(使う側)を分けますか? 使う側が作ったほうが良いですか(欲しい人が作る)? どのように動く どう周りを巻き込んでいくと良いですか 他に何が必要か 必要なものとして工数とスキルが浮かびますが、どうすれば確保できますか そのほか必要なものは何ですか