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
240
JANOG48_NW運用自動化の拡大/janog48_nwauto
mito
July 15, 2021
Tweet
Share
More Decks by mito
See All by mito
クラウドリフトとクラウドシフトで変わる運用/CODT2023
mito201
0
140
クラウドネイティブエンジニアを育成する/CNDT2022
mito201
1
610
Backlogをサポート窓口として活用する/JBUG_Summer_2022
mito201
0
820
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.1k
VBAから見たAnsiblePlaybookとの比較/diff-vba-ansible
mito201
0
530
Other Decks in Technology
See All in Technology
「改善」ってこれでいいんだっけ?
ukigmo_hiro
0
370
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
12
81k
Data Hubグループ 紹介資料
sansan33
PRO
0
2.2k
ローカルLLMとLINE Botの組み合わせ その2(EVO-X2でgpt-oss-120bを利用) / LINE DC Generative AI Meetup #7
you
PRO
0
110
プレーリーカードを活用しよう❗❗デジタル名刺交換からはじまるイベント会場交流のススメ
tsukaman
0
190
AWS UG Grantでグローバル20名に選出されてre:Inventに行く話と、マルチクラウドセキュリティの教科書を執筆した話 / The Story of Being Selected for the AWS UG Grant to Attending re:Invent, and Writing a Multi-Cloud Security Textbook
yuj1osm
1
100
Claude Codeを駆使した初めてのiOSアプリ開発 ~ゼロから3週間でグローバルハッカソンで入賞するまで~
oikon48
10
5.1k
事業開発におけるDify活用事例
kentarofujii
3
1k
「れきちず」のこれまでとこれから - 誰にでもわかりやすい歴史地図を目指して / FOSS4G 2025 Japan
hjmkth
1
340
OpenTelemetry が拡げる Gemini CLI の可観測性
phaya72
2
840
WEBサービスを成り立たせるAWSサービス
takano0131
1
190
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
8
1.1k
Featured
See All Featured
Balancing Empowerment & Direction
lara
5
690
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.5k
Optimizing for Happiness
mojombo
379
70k
Code Reviewing Like a Champion
maltzj
526
40k
Building Applications with DynamoDB
mza
96
6.7k
Into the Great Unknown - MozCon
thekraken
40
2.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
Mobile First: as difficult as doing things right
swwweet
225
10k
A Tale of Four Properties
chriscoyier
161
23k
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 誰が担当する 開発(作る側)と運用(使う側)を分けますか? 使う側が作ったほうが良いですか(欲しい人が作る)? どのように動く どう周りを巻き込んでいくと良いですか 他に何が必要か 必要なものとして工数とスキルが浮かびますが、どうすれば確保できますか そのほか必要なものは何ですか