開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2018/10/03

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

NoOps Meetup Tokyo #1

運用の嬉しくないことをなくそうとテーマで行われたNoOpsコミュニティのイベント「NoOps Meetup Tokyo #1」。このセッションに運用側、すなわちOpsの立場で登壇したのがマイクロソフトのソリューションアーキテクト真壁徹氏です。NoOpsコミュニティに対してOps側はどのような意見を戦わせようとしたのか。真壁氏のセッション「NoOps? よろしい、ならば戦争だ」を紹介します。

Publickey 新野淳一

Publickey 新野淳一

ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。

photo
NoOps Meetup Tokyoの会場となった品川のマイクロソフトには100人近い参加者が集まった

 参考:NoOpsを実現できる時が来た。「NoOps」とは運用の“嬉しくない”ことをなくすこと。NoOps Meetup Tokyo #1

NoOps? これは勝てる

 マイクロソフトでソリューションアーキテクトをやっている真壁と申します。

 ここに私が呼ばれた理由ですが、私は以前ZDNet Japanで「Opsの味方」という連載をやっていまして、そこに「NoOps」という言葉を突きつけた人たちがいると。では受けて立とう、ということです(会場笑い)

 とはいえ、私は負けるケンカはしないタイプなので、ちゃんと相手をリサーチしてきました。

 まずGoogleさん。もしかしたら結果がパーソナライズされているのかもしれませんが、「NoOps」で検索すると私の記事がいちばん上にきます。

photo

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

photo

 これは勝てると。

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

photo

 「Unconfortable Opsをなくす」とあります。おや、なかなかに紳士的な主張ですね。和解のワンチャンスがあるかも、と思います。

そもそもOpsとは? Opsは役割ではなくタスクである

 その前に、そもそもOpsとはなんだろうな、というのを皆さんと考えたいと思います。

photo

 DevOpsという言葉が出てきたころから、私はOpsという言葉に違和感がありました。

 あなたはDevですか? Opsですか? と聞かれたとき、自分はアプリを開発していないからどちらかというとOpsかな? とか。「どちらかというと」、という程度の分類じゃないですか。DevとOpsという分類は単純化しすぎです。

 これは私のDevとOpsについてのオレオレ定義ですが、私はDevとかOpsはタスクや行為だと思っています。

photo

 例えば、アプリを作る人も運用のオンコールに入ったり、なにか起きたときには対話のフローに入るでしょう。

 あるいは運用者が楽になる開発をしてくれる開発者もいます。

 だから私は、誰もがOpsを抱えていると思います。Opsというのは役割ではない。

photo

NoOpsを推進する3つのパターン

 もう少し冷静に、OpsとNoOpsに関する現状認識をお話したいと思います。

 NoOpsは新しく作るシステムでは実現しやすいのですが、既存のシステムをいくつも抱えている組織ではなかなか難しいところが残っていると思います。

photo

 SREという組織を作っているケースも増えていますが、従来型の運用も残っていますし、運用の自動化や無人化も進んでいますが、その裏側では人間が関わっていて、システムが壊れても自動的にリカバリできる仕組みがあったとしても、その仕組み自体が壊れたときには人間が関わらなくてはいけません。

 そこでNoOpsを推進するパターンは3つあると思います。

 1つは「グリーンフィールド」で、新しく作るシステムでアプリ開発者が「Uncomfortable Ops」をなくすように設計、実装すると。

photo

 ただこれでまったく運用がなくなる、というわけではないと思います。

 例えば、企業内の運用チームや外部のMSP(マネージドサービスプロバイダ)などに依頼して、そのシステムが外から見て正常に稼働しているかどうかを外形監視すると思いますし、なにか起きたときには誰かが一時対応するケースは多いのではないかと思います。

運用者自身がNoOpsをするパターン

 2つ目は、運用者自身がNoOpsをやっているパターンがあると思います。

photo

 運用する人が日々自分のやっていること、プロセスを見直して、これはいらないよね、という改善をしている人たちです。

 こういう話をすると、そうしたら自分で自分の仕事をなくしているのでは?、という人がいますが、自分たちが楽をするためにどんどん改善していこうとしている人は多いです。

SREの組織化

 最後のパターンがSREの組織化です。

photo

 よりプロアクティブに能動的に、アプリケーションの作りに対してこういう風にすると楽ですよ、といった働きかけや要請が高まります。

 SREを作ってプロアクティブに対応するか、リアクティブな対応も含めてひとつの組織として運用チームも一体化するか。どちらが多いかはいま揺れている頃かなと思います。

 で、何が言いたかったというと、NoOpsはやりたい人だけでは閉じない。周囲にいる人、特に運用をやっている人をいかに味方にするかが大事だと言うことです。

Opsの味方から、NoOpsコミュニティへの提案

 ですから、ここでNoOpsコミュニティに提案です。

 まず1つ目、Disらない。

photo

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

その他運用管理 ジャンルのセミナー

その他運用管理 ジャンルのトピックス

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!