- 2017年3月23日 StackStorm勉強会 第2回（Dmitri Zimine氏 来日講演）
- Event-driven automation, DevOps way ～IoT時代の自動化、そのリアリティとは？（Zimine氏 発表資料）
StackStormで変わる運用
2016年5月にStackStormを買収したBrocade Communications Systems, Inc. （以下「Brocade」）はStackStormを「ネットワーク・オートメーション・プラットフォーム」と呼んでいます（その後Brocadeを買収したBroadcom Ltd.が、StackStormを含むネットワーク部門をExtreme Networks, Inc.に売却）。この他にも「ワークフローエンジン」や「運用自動化ツール」などといった呼び方でStackStormを紹介するブログエントリなどが多数存在します。
それぞれが注目する特徴ごとにさまざまな呼び方をしていますが、StackStorm CTOのDmitri Zimine氏は、StackStormの本質は「IFTTT for DevOps」だと語っています（固有名詞として「IFTTT」というサービスがありますが、ここでは一般名詞としての「IFTTT」を想定しています）。
以下では「IFTTT」と「DevOps」の概念を解説します。これらの理解を通じて、StackStormの本質を紐解いて行きます。
IFTTTについて
「IFTTT（読み：イフト）」という単語は「IF This Then That」の略語で、あるシステムからの入力（イベント）に対して、全く別のシステムへ出力（アクション）するという考え方を表します。
IFTTTを実現する一例として、図1の上段のGitHub／JenkinsによるCI（Continuous Integration）、 CD（Continuous Delivery）がソフトウェア開発者にとって、なじみ深いと思います。
StackStormはStackStorm Exchangeがサポートするさまざまなシステム間で、相互にIFTTTを実現する仕組みを提供します。例えば、仮想基盤のイベントに対して、ロードバランサに対するオペレーションを行ったり、IaaSクラウドにおけるリソースの変更に伴い、Excelを更新するといった処理（またはそれらの組み合わせ）をYAML形式のファイルで記述することができます。
これにより、複数のシステムに跨る複雑なオペレーションを統一的に処理することができるため、多種多用なシステムの管理・運用コストを低減できると見込んでいます。
DevOpsについて
DevOpsは既にバズワードとなって久しく、「DevOpsを正しく理解しビジネスの価値を高める（中山 貴尋［著］）」など多数の解説があります。
一般的に「DevOps」とは、何がしかの情報サービスに関わる人間を開発者（Developer）と運用者（Operator）に分類し、それぞれの職責を「サービスに対する機能開発によるビジネス価値の向上」と「サービスの継続稼働によるビジネス価値の向上」とした場合、それぞれの仕事がお互いのリスクになる構造に対して、アジャイル開発などの技法や各種ツールを用いて、お互いのリスクを最小化しながら目的（ビジネス価値の向上）を実現する取り組みを表します。
冒頭で示した記事で紹介されている「DevOps導入指南 Infrastructure as codeでチーム開発・サービス運用を効率化する」でも、DevOpsは
Dev（開発）とOps（運用）が密に協調・連携して、ビジネス価値を高めようとする働き方や文化（「Chapter1-1:DevOps登場の背景」より抜粋）
と解説されています。
注意していただきたいのは「DevOps」が成立する対象は必ずしも「開発者（Dev）」と「運用者（Ops）」だけではないことです。「DevOps」の本質は、それぞれの役割が局所最適化した組織・人同士において、それぞれが連携して全体最適（ビジネス価値の向上）を図ることなので、大局的な利害が一致する組織・人同士であれば、立場の名称に関係なく「DevOps」は成立すると考えられます。ここでStackStormがどのように「DevOps」を実現するかの一例を簡単にご紹介します。
次の図2は何がしかのビジネスを支えるシステム（System）と、システムを管理・運用するチーム（Team）、及びそれぞれのシステムを利用するユーザー（User）を表しています。
ここではユーザーが業務を効率的に行うためにそれぞれのシステムを利用し、各チームはそれらのシステムを維持し、ユーザーに提供する役割を負っていると仮定します。
チームはユーザーに対してシステムの存在を周知し、システムの使い方を示したマニュアルを作成します。
しかし、チームによる周知不足のためユーザーがシステムについて認知していない場合（System-A）や、マニュアルがないなどの理由でシステムの使い方がわからない場合（System-C）には、ユーザーはそれらのシステムを利用できません。
またユーザーがシステムを認知し、使い方を把握していたとしても、複数のシステムを利用する場合には、ユーザーはそれぞれのシステムの使い方を覚えなければなりません。
これに対しStackStormは、それぞれのシステムを抽象化し、ユーザーに対して全てのシステムを統一的に扱えるインターフェイスを提供します。
StackStormによるシステムの抽象化により、システムを運用する各チームがシステムの各機能をStackStormに登録することで、全てのユーザーが全てのシステムの機能を認知・利用できるようになります。
システムを利用するユーザーにとっては、全てのシステムを統一した方法で横並び（システムごとの使い方の差異をほとんど意識せず）に利用することができるため、より効率的に業務ができると考えられます。
システムを提供するチームにとっては、システムのオペレーションをStackStormに統合することによってユーザー周知のための作業コストが減り、またインターフェイスを統一化させることによって、使い方を説明するための作業コストも減らすことができます。
このように、ユーザーとチームの双方がStackStormを共通認識として持つことで、機能の追加・利用・フィードバックのサイクルをスムーズに循環させ、冒頭で解説した「DevOps」を実現できると考えられます。
まとめ
StackStorm CTOのDmitri Zimine氏が語った「IFTTT for DevOps」が何を意味するかについて解説しました。ここまでの内容で、多種多様なシステムを組織的に運用する場面でStackStormが効果を発揮しそうだということを理解いただけたかと思います。
次回は、各社がどのようにStackStormを利用しているかの事例を紹介します。
