- 会員限定
- 2018/10/03 掲載
NoOps? よろしい、ならば戦争だ
NoOps Meetup Tokyo #1

参考:NoOpsを実現できる時が来た。「NoOps」とは運用の“嬉しくない”ことをなくすこと。NoOps Meetup Tokyo #1
NoOps? これは勝てる
マイクロソフトでソリューションアーキテクトをやっている真壁と申します。ここに私が呼ばれた理由ですが、私は以前ZDNet Japanで「Opsの味方」という連載をやっていまして、そこに「NoOps」という言葉を突きつけた人たちがいると。では受けて立とう、ということです(会場笑い)
とはいえ、私は負けるケンカはしないタイプなので、ちゃんと相手をリサーチしてきました。
まずGoogleさん。もしかしたら結果がパーソナライズされているのかもしれませんが、「NoOps」で検索すると私の記事がいちばん上にきます。

では好きな人は好きな検索エンジン(注:Bingのこと)で検索すると、1番目の記事には「NoOpsという用語は不適切です」という説明があるんですね(会場笑い)

これは勝てると。
でも勝利を万全のものにするため、NoOpsの主張を確認しましょう。

「Unconfortable Opsをなくす」とあります。おや、なかなかに紳士的な主張ですね。和解のワンチャンスがあるかも、と思います。
そもそもOpsとは? Opsは役割ではなくタスクである
その前に、そもそもOpsとはなんだろうな、というのを皆さんと考えたいと思います。
DevOpsという言葉が出てきたころから、私はOpsという言葉に違和感がありました。
あなたはDevですか? Opsですか? と聞かれたとき、自分はアプリを開発していないからどちらかというとOpsかな? とか。「どちらかというと」、という程度の分類じゃないですか。DevとOpsという分類は単純化しすぎです。
これは私のDevとOpsについてのオレオレ定義ですが、私はDevとかOpsはタスクや行為だと思っています。

例えば、アプリを作る人も運用のオンコールに入ったり、なにか起きたときには対話のフローに入るでしょう。
あるいは運用者が楽になる開発をしてくれる開発者もいます。
だから私は、誰もがOpsを抱えていると思います。Opsというのは役割ではない。

NoOpsを推進する3つのパターン
もう少し冷静に、OpsとNoOpsに関する現状認識をお話したいと思います。NoOpsは新しく作るシステムでは実現しやすいのですが、既存のシステムをいくつも抱えている組織ではなかなか難しいところが残っていると思います。

SREという組織を作っているケースも増えていますが、従来型の運用も残っていますし、運用の自動化や無人化も進んでいますが、その裏側では人間が関わっていて、システムが壊れても自動的にリカバリできる仕組みがあったとしても、その仕組み自体が壊れたときには人間が関わらなくてはいけません。
そこでNoOpsを推進するパターンは3つあると思います。
1つは「グリーンフィールド」で、新しく作るシステムでアプリ開発者が「Uncomfortable Ops」をなくすように設計、実装すると。

ただこれでまったく運用がなくなる、というわけではないと思います。
例えば、企業内の運用チームや外部のMSP(マネージドサービスプロバイダ)などに依頼して、そのシステムが外から見て正常に稼働しているかどうかを外形監視すると思いますし、なにか起きたときには誰かが一時対応するケースは多いのではないかと思います。
運用者自身がNoOpsをするパターン
2つ目は、運用者自身がNoOpsをやっているパターンがあると思います。
運用する人が日々自分のやっていること、プロセスを見直して、これはいらないよね、という改善をしている人たちです。
こういう話をすると、そうしたら自分で自分の仕事をなくしているのでは?、という人がいますが、自分たちが楽をするためにどんどん改善していこうとしている人は多いです。
SREの組織化
最後のパターンがSREの組織化です。
よりプロアクティブに能動的に、アプリケーションの作りに対してこういう風にすると楽ですよ、といった働きかけや要請が高まります。
SREを作ってプロアクティブに対応するか、リアクティブな対応も含めてひとつの組織として運用チームも一体化するか。どちらが多いかはいま揺れている頃かなと思います。
で、何が言いたかったというと、NoOpsはやりたい人だけでは閉じない。周囲にいる人、特に運用をやっている人をいかに味方にするかが大事だと言うことです。
Opsの味方から、NoOpsコミュニティへの提案
ですから、ここでNoOpsコミュニティに提案です。まず1つ目、Disらない。

【次ページ】 新しいことを始めるとき、正義感からか過去をDisるケースが出るが…
関連コンテンツ
関連コンテンツ
PR
PR
PR