「NoOps？ よろしい、ならば戦争だ」 NoOpsコミュニティに異議申し立てた「Opsの味方」 決裂か？ 和解か？ NoOps Meetup Tokyo ＃1

運用の嬉しくないことをなくそうとテーマで行われたNoOpsコミュニティのイベント「NoOps Meetup Tokyo #1」。このセッションに運用側、すなわちOpsの立場で登壇したのがマイクロソフトのソリューションアーキテクト真壁徹氏です。

NoOpsコミュニティに対してOps側はどのような意見を戦わせようとしたのか。真壁氏のセッション「NoOps？ よろしい、ならば戦争だ」を紹介します。

参考：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るケースが出てきてしまします。ただそれぞれの持ち場で頑張っている人たちを無意識にDisらないようにしてほしいと思います。そうでないと、運用者が協力しようとしたときに気持ちがくじかれてしまうかもしれないので。

2つ目、「べき論」はいらないのではないかと。

NoOpsに限らないですが、最近やたらと「べき」が多いと思いませんか？ NoOps界隈だと、こんな「べき論」が出てくるのではないですかね。

ちょっとハードルが高すぎて引きますよね。

私の今日のダジャレはこれです。「べき」じゃなくて「武器」じゃないかと（会場笑い）。

誰を向いて仕事をしているか、だれに貢献するか。それはお客様や仲間だったりすると思いますが、そのときどきに必要となる手段、それは相手で変わる。

べきで画一化するより、いろんな武器使いがいた方が面白いのでは。

前向きにやめる

そして最後の提案です。これがいちばん言いたいことです。

それは、前向きなやめ方、やめるファースト戦略を共有しようと。

戦略的にやめないと、新しいことができませんよね。

マイクロソフトの社内の話ですが、オンプレミスにあった6万台のサーバを撤廃し、Azureへ移行した例がありました。

どうやって移行を検討したのか。

まず最初の判断基準は「退役」です。このシステムを移行せずに捨てられないか。

次にSaaSへ移行できないか。それができなければ適切なPaaSがないか、それもなければIaaSに、としました。

私は以前、日本ヒューレッット・パッカードにいたのですが、そのとき社内のシステムをVMwareで統合したときも、まず「このシステムは捨てられないか」から始めて、捨てられなかったら仮想化基盤に乗せることにしました。

なので、まず捨てられるか考えるというのは、もしかしたらITの世界では、日本以外ではコンセンサスなのではないかなと思います。

「ノー」と言いやすいキャラになろう

すると次に、この問題に必ずぶち当たります。それは、捨てられる、止められることを誰が決められるのか、ということです。それを自分で決められるという人は、それほど多くないと思います。

ただ、このNoOpsコミュニティの第一回に参加した皆さんなら、社内で「ノー」と言いやすいキャラになれるかもしれません。しかも前向きに。

決める人はおそらく偉い人ですから、その人に「こうだから捨てられませんか」という話を前向きにできるようになればいいなと。

そのためには技術だけでなく説得力のあるネタが必要だなと思います。こういうネタをNoOpsコミュニティで技術の話だけでなく、こうやって社内のシステムをなくしたよ、といったストーリーなども共有してほしいと思います。

テクノロジーとストーリー、これを共有して、コミュニティに閉じこもらず、決める人にも届くようにと願っています。

（NoOps Japan発起人 岡大勝氏）「その提案、受け入れさせていただきます」

ということで、いま私はここに「NoOpsの味方」を宣言して終わりにしたいと思います。

下記は公開されている資料。

NoOps Meetup Tokyo #1

• NoOpsを実現できる時が来た。「NoOps」とは運用の“嬉しくない”ことをなくすこと。NoOps Meetup Tokyo ＃1
• 「NoOps？ よろしい、ならば戦争だ」。NoOpsコミュニティに異議申し立てた「Opsの味方」。決裂か？ 和解か？ NoOps Meetup Tokyo ＃1