NoOps?よろしいならば戦争だ

NoOps?
真壁徹
日本マイクロソフト株式会社
2018/09/12
よろしいならば戦争だ
NoOps Meetup Tokyo #1

自己紹介
{
“名前” : “真壁徹(まかべとおる)”,
“所属” : “日本マイクロソフト株式会社”,
“役割” : “クラウドソリューションアーキテクト”,
“経歴” : “大和総研 → HP Enterprise”,
“特技” : “クラウド & オープンソース”,
“Twitter” : “@tmak_tw”
}

連載: Opsの味方 (ZDNet Japan) 2016/10～12

NoOps？
よろしいならば戦争だ

わし
おか氏
かわさき氏

主張を確認しよう
NoOps = No "Uncomfortable" Ops
NoOps Japanでは「システム運用保守の"嬉しくない
こと"をなくそう！」をテーマに、 NoOpsを実現する
ための技術・設計手法・開発運用保守サイクル・ツー
ルや考え方・事例などを共有していきたいと考えてい
ます。
NoOps Meetup Tokyo #1 recovery イベント概要より

おや？なかなかに紳士的
和解のワンチャンあるか

ところで、そもそも”Ops”って何なんでしょうか
Dev
Ops
アプリ
インフラ
？

わたしの主張
Opsという呼び方が嫌い
さて、『Opsの味方』というタイトルで連載を始めた
わけですが、私はOpsという呼び方が嫌いです。とっ
ても。連載のしょっぱなから取り乱して申し訳ありま
せん。
Opsの味方連載第1回 “「NoOps」の時代がこない理由”より

A氏「はじめまして。Devですか？Ops？」
B氏「(アプリ開発してないからなぁ)」
B氏「どちらかというとOpsです」

単純化しすぎじゃなかろうか

オレオレ定義
アプリ
インフラ
作る(Dev) 維持する(Ops)
アプリ
開発者
インフラ
開発者
アプリ
運用者
インフラ
運用者

誰もがOpsを抱えている

Ops ≠ 人、役割
Ops ≒ タスク

再び主張を確認
NoOps = No "Uncomfortable" Ops
NoOps Japanでは「システム運用保守の"嬉しくない
こと"をなくそう！」をテーマに、 NoOpsを実現する
ための技術・設計手法・開発運用保守サイクル・ツー
ルや考え方・事例などを共有していきたいと考えてい
ます。
NoOps Meetup Tokyo #1 recovery イベント概要より

良いこと言うぜ
ここはひとつ和解交渉を

NoOpsに加勢する前に、現状認識
新しく作るシステムではNoOpsしやすい
SREを組織化するケースが増えているが、従来型の運用も残っている
自動・無人化の裏で、誰かが運用に関わっている
自動・無人化された仕組みが壊れた時、その作り手が運用者になる
何事も急には変えられない

NoOps推進パターン① グリーンフィールド
アプリ
インフラ
アプリ
開発者
インフラ
開発者
アプリ
運用者
インフラ
運用者
• アプリ開発者
が”Uncomfortable Ops”
を減らすよう設計、実
装する
• 新たに作るシステムで
やりやすい
• アプリ開発者は従来以
上に運用に踏み込む
• 組織共通の運用は運用
者に任せる (セキュリ
ティ周り、外形監視な
ど)

NoOps推進パターン② 運用者の自発的進化
アプリ
インフラ
アプリ
開発者
インフラ
開発者
アプリ
運用者
インフラ
運用者
• 運用者自ら
が”Uncomfortable Ops”
を減らす仕組みを作る
• 「自分の仕事がなくな
るのでは？」なんて大
きなお世話と思ってい
る
• 強い運用組織には新た
な仕事が集まる
• アプリの作りまで踏み
込まないことが多いか
も

NoOps推進パターン③ SRE組織化
アプリ
インフラ
アプリ
開発者
インフラ
開発者
アプリ
運用者
インフラ
運用者
• ”Uncomfortable Ops”を
減らす組織を作る、ま
たは位置づけを新たに
する
• 能動的にアプリの作り
まで踏み込む、アドバ
イザーとなる
• カバー範囲は広い
• 運用チームを一体化す
る場合もあれば、しな
い場合も

つまりNoOps推進者だけで閉じない
いかに周りを巻き込むか/味方を作るか

NoOps Japan Communityへの提案
第1条: Disらない

Disって何かが解決するか？
NoOps過激派運用者
直接的/間接的
Disrespect
従来のOpsがイケ
てないから、ぶっ
壊すぞ！
自分の持ち場で貢
献しているのに、
つらい
(正義は時に人を鈍感にし、
責めている自覚がなくなる)
協力しようと思ってたのに

NoOpsに価値があると信じるなら
Disる必要はない

第2条: べき論不要

界隈は「べき」にあふれている
本当にそうなのだろうか
インフラエンジニアもコードを書く「べき」
アプリ開発者が運用自動化の設計をする「べき」
IaaSよりPaaSを使う「べき」
クラウド技術者もハードウェア技術を学ぶ「べき」
勤務時間外も勉強する「べき」
英語ができる「べき」

ハードル高すぎ
ちょっと引く

「べき」じゃなく「武器」
その要否は貢献したい相手(顧客、仲間)で変わるあくまで手段
インフラエンジニアもコードを書けたら「武器」
アプリ開発者が運用自動化の設計をできたら「武器」
IaaSに加えてPaaSも使えたら「武器」
クラウド技術者もハードウェアの知識があれば「武器」
勤務時間外も勉強するほど意欲があるのは「武器」
英語ができたら「武器」
べき

「べき」で画一化するより
いろんな「武器」使いがいたほうが面白い
オクトパストラベラー、楽しいですよね

第3条: 前向きな「やめ方」を共有しよう

やめるファースト戦略
前向きに「No」を掲げて「やめる」
やめる、捨てることが苦手ではありませんか？
前任者への(本質的じゃない)敬意？
「もったいない」 DNA？
従来の仕組みを維持したまま、新しいことができるか？リソースはあ
るか？余裕はあるか？
できる戦略家は、まず「やめること、やらないこと」を決める

やめた例: マイクロソフト社内ITのクラウド移行
やめることを決め、新たな挑戦に必要なリソースと余裕を得る
<各システムの移行検討順>
1. 退役
2. SaaSに移行 & 新規利用
3. PaaSに移行
4. IaaSに移行(最適化)
5. IaaSに移行(Lift & Shift)
NoOps的
腕の振るい
どころ
• オンプレミスにあった
60,000サーバーを撤廃し、
クラウドへ移行
• NoOpsな腕を振るう前に
「このシステムは退役で
きないか」考える

「やめる」ことを決められるか？
誰が決めるのか？

僕たちは、前向きな「No」を
提案しやすいキャラになれる

決める人を動かしたストーリーを共有しよう
小さなことでも、前向きに「やめ慣れ」るために
おう、やめて
いいよ！
ブルーグリーンデプロイで
平日でもバージョンアップ
できる仕組み作ったので、
恒例の年末年始・連休出勤
は無くしていいですよね？
あのレポート、人力コピペ
がつらいんですけど、誰も
見てないのでやめていいで
すか？データは自動集計し
て置いておくので
あのシステム、もう3人し
か使ってないっす。すでに
使ってるSaaSのプチ機能で
似たようなことできそうな
ので、退役させませんか？
決める人

NoOpsな技術とストーリーを共有し
コミュニティに閉じこもらず
「決める人」へも届くように

ここに「NoOpsの味方」を宣言します
2018/09/12 まかべ

NoOps?よろしいならば戦争だ

More Related Content

NoOps?よろしいならば戦争だ