- 踊るホスティティングサービス
- 変化を強いられる時代
- 壁を越え、進む
- あの日僕が BASIC に挫折した事を忘れない
- オープンソースを積極活用、そして一次対応へ
- 閾値主義からの脱却
- 一次対応の闇
- 一度は仕事を辞める覚悟をした
- 正直、もう人間が運用や監視対応するのは限界かもしれない
- Serf the Librator ――運用対応自動化が、進化への鍵か
- 今日よりも鮮やかに
概要と書きたかったこと
師走です。年の瀬ですね。寒くなりましたね。コタツが恋しいです。ミカンおいしいです(^q^)
そんな季節柄、ふと、自分の仕事を振り返りたくなりました。
僕はこれまで、ホスティングサービスの中の人として歩んできました。自分が何を考え、どのように行動を起こしてきたか。その経緯は、今の自分しか書けない気がして。色々なスライドや twitter では伝えきれなかった事を、一度まとめたいなぁと。なので、こうやって文章として書き留めることにしました。
伝えたかった事を三行でまとめると、
- インターネットは、もう「あちら」の世界ではない。
- 運用の役割は、点（障害対応技術）から面（サービス品質維持）に変わりつつあるのでは。
- 世界の壁が無くなるのならば、運用も変えて行こう。変わる勇気を持とう。
このような内容。経験論でもなければ、何か格好いいことが書きたかったわけでもなく、実際はカッコわるいというか、闇に近いかも。なお、ベースになったのは、オープンソースカンファレンス 2013 Tokyo/Fall で発表したオープンソース文化とホスティングの未来です。このスライドの行間を埋める意味もあります。
それと、これは無理ですが、6年前の自分に伝えたかった事とか。
今は唯々、僕の心境を書き綴ります。
なお初稿は、雪の降る、富山県滑川市の実家で書き始めました。現実逃避というか（し、進捗だめです・・・ごめんなさい）割と軽い気持ちで始めたのですが、気がつけば自分の振り返り的な文章になったような。
いや、これは完全に現実逃避でしょう。どうしてこうなった。
踊るホスティティングサービス
ホスティングサービスは、ネットワークを通して、サーバ（コンピュータ資源）を提供するサービス。事業者さんによって定義は変わります。僕の所属する会社では、データセンタ内の物理サーバやネットワーク環境を、リモートのお客さまに提供しています。その中でも、ここ3年は、SNS に関連したソーシャルアプリやゲーム、ウェブサービスの運用やサポートに携わりました。そして、僕の仕事は、いわゆるインフラエンジニア的だったり、サーバエンジニア業務が中心です。
仕事の中で転機があったのは 2009 年頃。感じたのは、彼ら達（アプリ開発者）のスピード感に追いつくには、どうしたらいいのだろうと。丁度、SNS 各社がプラットフォームのオープン化を行った頃です。オープン化は API を通して SNS のユーザ情報が利用できるだけでなく、外部のサービスと連動する所も鍵でした。誰でも規格を満たせば、サーバさえあれば、サービス提供ができるようになったからです。
そして、徐々にサーバに対するリクエストも変わってきます。より「いますぐ必要！」「たくさん必要！」となりました。理由は、SNS 利用者の増加。サービス展開を始めると、大人数の SNS 利用者に晒される事になります。初動でも、数万人～数十万人規模のアクセスを想定しなくてはいけません。
極端な話では、今日中に100台サーバが欲しいんだ。2ヶ月しか使わないけども、といったような案件も。
従来、サーバが欲しくても納品まで数週間ほど必要なケースがありました。メーカやベンダに見積もりを取り、時間を経て納品。それからも時間はかかります。サーバの BIOS や RAID コントローラを調整し、ラックに設置し、ネットワークを結線し、OS のセットアップ。
「今すぐ使いたい」というのに、調達に時間がかかるようでは、間に合いません。これではチャンスを逃してしまうのだと。それに加え、サービス提供後の拡張スピードと、インフラ増強が追いつかない（後から追加発注していたら間に合わない）という事もありました。
そのような事情もあり、丁度、コロケーションサービス（機材をデータセンタ内の、専用ラックに持ち込み）利用拡大や、自作サーバでサービス展開を行われる事業者さんが増えてきています。
僕等はホスティングサービスなのですが、危機感が走ります。このままでは必要とされていない、不要なサービスになってしまう、そう、切々と感じていました。
変化を強いられる時代
このような状況の下、まずはサービスの再定義から始めました。「お客さまが本当に必要な機能は何か？」を、「自分が利用者の立場だったら、どんな機能が欲しいか？」におきかえて。ただし、手持ちの武器（物理サーバ）しか使用しないという縛りの中、いかに速くサービスを提供するか。
まずは、お客さまへのヒアリングです。当時の僕はサービス開発部という部署に所属しており、どちらかというと企画に近い立場でした。お客さまが欲しいものは何なのか、営業訪問に同行して、情報を整理。正面からだけじゃなく、各社さんの技術者ブログを拝見したり、勉強会で技術の流行廃りを調べたり、肌間隔で、手探りで。そしてクラウドコンピューティングなる概念と出会います。
そして、どうやら技術としてのクラウドというより、ビジネスとしてのクラウドが当時は求められているのかも、という仮説に至ります。
これは、クラウドの利用形態を、公共サービスに例えた表現がヒントでした。サーバ資源を、電気料金や水道料金に例えると、初期コストをかけずに、使った分だけ課金されるというモデル。非常に分かりやすい、上手いなと。そして、もし物理サーバでも同じような利用形態が実現できるなら面白いのではないかと。
SNS で利用されるアプリやゲームでは、サービス提供直後のアクセス数やトラフィックを乗り切る環境が必要でした。潤沢なサーバ資源を、必要な時に必要なだけ使いたい。そういう要望があるのではと考えたのです。それに、単純に数を増やすだけでなく、減らす事も簡単にできる必要があるとも感じます。
補足しておきますと、まだ「仮想化」と「クラウド」の概念が混ざって解釈されていた頃。ただし、大規模なアクセスやトラフィックを処理するには、当時は物理サーバを並べた方が導入の敷居が低く、高速な半導体ストレージも使う事が出来るという利点もありました。
このように仮説を立てたあとの動きはスムーズでした。あとは仕組みを作るだけだと。
まずは、環境構築。いくつかの専用ラックに予めサーバ群やスイッチ類を集積します。予め拡張可能なように、広帯域の回線やロードバランサ・ファイアウォールを調達します。しかし、機材が揃っただけでは足りません。サービスの仕組みとして、物理サーバなのに初期費用０円という枠や、日割りで課金可能な体制。そしれ、それらをオンラインで完結できるコントロールパネルの自作も行います。
このとき、サービスの企画開発担当者は2人のみ。開発手法は、とにかく作って形にして、サービス提供を開始するというもの。スピードが最優先でしたので、ネットワーク図以外は細かな仕様書はありません。コントロールパネルも、必要な機能を箇条書きにして、最低限動けば良い。とにかくコードを書いていきました。今考えますと、正解だったのではと思います。始めから完璧を追い求めていたら、いつまでたってもリリースできなかったと思います。
また、自分のできない所は同僚の力を借りました。ネットワーク構築は、自分の苦手な所なので、データセンタの対応チームにお願いし、助けてもらいました。技術的な要素より、むしろ難しかったのは、社内との調整。課金体系だけでなく、申込解約に関する社内手続きも、ゼロから構築する必要がありました。ここも、社内の協力を得られ、サービスの形が見えてきます。自分達のチームだけでやろうとしますと、多分、もっと無駄に時間がかかったはず。今でも本当に感謝しています。
そして、何とかサービス提供開始に漕ぎ着けます。ですが、ここで終わりではありませんでした。今から思えば、まだ、ほんの始まりに過ぎなかったのです。
壁を越え、進む
まさか、自分たちも一次対応や監視を行うとは、当時は想像すらしていませんでした。
チームの役割はサービスの企画開発。本来であれば、サービスリリースによって一段落するところ。とはいえ、SNS をはじめ、スマートフォンの登場など、世の中の変化は続きます。継続的な機能追加やサービス拡張のため、プロジェクトは継続します。
この頃に考えていたのは、壁を壊すという事。SNS の普及により、ネットワークやサーバのインフラ基盤はかくあるべき、という常識は崩れ去りました。世の中が変わっていくのであれば、僕も変わらざるを得ません。守りに入って壁を作るんじゃなく、壁を残り得ていかなくてはと。
そして、業務ではネットワークそのものが新サービス向けに特化していましたので、僕等は二次エスカレーション対応を行う事になります。加えて、営業活動にも積極的に同行しました。そこで、お客さまとコミュニケーションを取りつつ、最新の技術動向を教えていただき、サービスの至らない点があれば直接指摘いただきました。
その指摘事項の中で、僕が気になっていたのが、一次対応サポートに対する要望です。彼らとしては、新しい技術をどんどん取り入れていきたいですし、可能であれば、技術的なサポートをして欲しいと。確かに、決まり切った対応しかできないんだったら、お客さま自身が動いた方が速い対応ケースもあるでしょうし、それだとホスティングの存在意義が必要なくなってしまいます。
ここで少し、気がつきました。あっ、自分の中で壁を作ってるな、守りに入ってるな。
あるお客さまからの一言が、背中を押します。「解決出来なくてもいい、一緒に悩んで欲しい」と。それに、お客さまがやりたいのはアプリなりサービスの運用であって、ハードウェアやインフラの部分はお任せしたいのだと。そう言われれば、あとはやるだけ、覚悟するだけ。たまたま、僕自身はオープンソース周りの技術検証が好きでした。そのため、持てうる範囲で情報提供なり技術サポートを始めます。一次対応チームで足りないなと感じるところは、自分から追加情報を補足したりして、二次対応の幅を広げていきます。
また、一部のお客さまとは Skype でのやりとりを導入したり、ホットラインを作る（プライベートの携帯電話番号を伝えて）など、出来うる事には取り組んだつもりです。
サポート対応に拘るのは、ちょっとした理由があります。
あの日僕が BASIC に挫折した事を忘れない
僕が小学1年生の時、家にパソコンが届きます。父親が買ったのですが、あまり使わなく、僕が玩具変わりに。機種は SHARP の X1 （エックスワン）という機種。OS ( BASIC ) を読み込むのに、カセットテープを使っていた時代。フロントをパカッと開いて、カセットを差し込んだあと、閉じて読み込み開始。1分ほどしたら、ようやく BASIC が使えるようになります。何か BASIC 上でプログラムを読み込むときは、改めてカセットを読み込み直して…という事をしていました。
そんな僕の目の前には、X1 の他、数冊の PC 雑誌がありました。雑誌には、BASIC で書かれた投稿プログラムが沢山。見様見真似で打ち込もうとするのですが、当時の僕には敷居が高すぎました。小学一年で、そもそもアルファベットは読めません。正確に打っているつもりも、入力エラーで Syntax Error の嵐。子どもながら、パソコン凄い！と思っていたのですが、まわりにプログラムについて訊ける大人はいない。はぁ、途方に暮れた結果、X1 は只のゲーム機に成りはてます。
今でも思うのは、あのとき、僕の周りに BASIC の分かる誰かがいたらなぁと。
時間が経ち、小学5年生になりますと、地区公民館でパソコン教室がありました。親に連れられて行くと、そこには PC88 や PC98 などが5～6台。そこで改めてパソコンに出会い、色々教えていただきました。地方では、今のようにどこでもパソコンが売られていませんでした（コンピュータに触れるには、滑川市から富山市まで1時間かけてようやくたどり着けるような）。それから、たまたま学校でパソコン通信やインターネットに触れる機会があり、たまたまパソコン通信のホストを開局したりする環境があり、仲間達がいて、ICQ に出会います。
インターネットの可能性を感じたのは ICQ というソフトとの出会い。今で言う LINE や Skype の走りでしょうか。当時は常時接続が普通ではなく、テレホーダイという夜間早朝一定通話料のサービスが始まりました。相手がパソコンの前にいるかどうかは分からないのです。けれど、ICQ ならオンラインかどうか見て分かりますし、携帯のメールを使わなくても文字メッセージをやりとりできる。こんな便利なソフトが無料で公開されていて、使わざるを得ないと。
ICQ そのものは簡単なツールなのに、海外のソフトなのでマニュアルが全て英語。僕は ICQ の日本語化パッチを作ったり、ICQ 道場という、簡単な紹介ページを作ったりしていました。勝手サポート掲示板も作ったりし、良いものは皆で使っていければなと。ICQ を通して、インターネットを便利に使える人が増えればなぁと。
この気持ちは、BASIC に躓いた・分からなかった悔しさが自分の中にあったから。
そして、たまたま富山県にホスティング企業があると知り、学生のバイト時代を経て会社に入りました。ホスティングで扱っている OS は Linux が中心でした。そして、ホスティングと ISP の一次対応を行うようになります。そこで、サポートとは何か、サービスとは何かを考える事になります。
本来はサービスとは、利用規約なり契約に定められている事以外は、する必要が無いと言えます。しかし、実際には微妙なトラブルも多く起こりました。たとえば、Apache なり Linux のコマンドが分からないといったもの。あとは、CGI まわりの設置で苦労されていたり、環境の違いで動かない場合など。
その頃、僕はたまたま Perl を書けたので、CGI の設置支援や、動かないスクリプトのデバッグなど、半分趣味の延長のような形で関わっていました。背景にあったのは、僕が BASIC を理解できなかった、という強烈な体験があったから。だから、お客さまが困っているのであれば、それはサービスの範囲内で、出来るだけお客さまの力になりたいと思っていました。これは、今も変わらない思いです。
これは、ビジネスとして良かったかどうかは今も分かりません。ですが、お客さまとの関係を考える、いいきっかけになったと思います。中には、お金を払っているんだからやれよ、と、失礼ながら超上から目線のお客さまもいらっしゃいました。それでも、一緒に頑張ろう！という雰囲気のお客さま（いや、もしかしたら僕がそう思い込んでいただけかもしれない）とは、良い経験を積ませていただいたと思います。
そういう思いもあり、技術サポートだけは、出来るだけ丁寧に、かつ迅速に出来るよう心がけてきました。
しかし、それだけでは足らなかったのです。
思いだけで世の中が良くなるのであれば、どんなにいいことか。
オープンソースを積極活用、そして一時対応へ
再び話をサポート対応に戻します。
様々なオープンソースも、積極的にサービスに投入しました。特に監視系が一番大きく変わった所です。サービス展開時は、Munin を監視オプションとして提供します。2013年に入り、Zabbix もサービスの裏側（社内での通知/監視システム）として実環境で使っています。これは、自分たちの運用スタイルが変わった事が大きな影響です。
元々は、運用チームの中でも二次対応を僕等は行っていました。お客さま毎に、数十台規模の環境をお預かりしていますが、トラブル発生の調査に時間がかかりがち。そこでリソース監視ツールの Munin は大きな効率化をもたらしました。
もしも Munin がなければ、トラブルシュートのために、まずは各種のログを見るためにサーバにログインしなくてはいけません。しかも台数が多いときは、手間も増えますし、何より解決するまでの時間がかかります。
一方、Munin があれば、グラフを見るだけでアタリをつけることができます。全サーバの CPU やメモリ、ネットワーク等、各種のリソースが時系列でグラフを通した参照が出来ます。グラフを通して、異常値の特定や、通常と違う挙動をしている所が視覚的に把握できました。それに、対象サーバで障害が発生してログインできなくても、グラフを見るだけで状況が分かるのは画期的。トラブルシュートにおいて Munin は欠かせない存在になります。そのあたりを経緯をまとめたのが、スライド「サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて」だったのです。
ちなみに、オープンソースを積極的に使った理由。何かあったら自分で解決できるのが大きなポイントでした。Munin は Perl で記述されてており、データ収集プラグインも perl かシェルスクリプトが中心。自分が得意な言語のため、必要に応じてプラグインを追加したり、書き換えたりするのも容易でした。
そのような運用を続けていたある日、ネットワーク全体を巻き込むような大規模障害が発生してしまいます。
今から思えば甘かったのですが、データセンタ側の機器については監視対象外でした。そのため、都度、確認のため電話でのやりとりが発生します。これが致命的でした。状況把握に時間がかかりすぎ、結果として機会損失を発生させてしまいます。
この時の教訓から、監視範囲を拡大します。データセンタ側と交渉し、SNMP 情報の開示など、自分たちでもネットワーク全体の状況を分かるように体制を作ります。トラブルがあって手出しできなかったとしても、自分たちで監視できれば、状況は把握出来ると。そして、Zabbix を使い監視を行うことになります。
Zabbix も PHP で記述されたオープンソースとして公開されていました。Zabbix を検討する頃は、日本支社の設立がされた直後でしたが、何かあれば訊くことが出来る窓口がある、というのも導入を後押ししました。基本は自分たちで対処するつもりですが、本当に何か困ったときにお客さまに迷惑をかけるわけにはいかない、その後ろ盾が欲しかったのです。
監視範囲を拡大するだけではなく、案件によっては直接一次対応を行う事も始めます。どうしても、スピード感が求められるケースでは、中に人を通すのではなく、自分たちも監視して、対応するのが一番速いだろうと。
そして、チームの勤務地をデータセンタの中に移すことになりました。これまではリモート対応でしたので、少々の心理的な抵抗はありました。けれど、結果としては移動して正解。緊急時には、データセンタ内のチームと直ぐに連絡を取り合い状況確認できますし、必要があれば自分たちも直接設備フロアに入り込んで、状況を確認することもできました。
閾値主義からの脱却
一次対応を行う際は、少人数のチームで、いかに運用効率を上げるかを考えます。より速く対応するために、メール（インシデント）毎の対応をやめました。従来の対応では、異常検出時にシステムからメールが送信され、そのメールに都度対応を行っていました。
しかし、大規模なネットワーク障害が発生する可能性を考えますと、このままではいけないなと。もし、数千通に及ぶメールが一斉に届いたらどうしましょう。メーラー側で保存フォルダを分け、色を付けるなどの対応は可能かもしれません。しかし、件名やメール本文に眼を通すだけでも時間がかかってしまいます。
そこで活用したのが、Zabbix のトリガ一覧表示です。トリガ画面は「今」問題が起こっている機器やリソースを表示します。それに、並び替えも出来るのが便利。時系列や名前だけでなく、深刻度に応じた表示が出来ます。予め、重要なスイッチやネットワーク機器に対しては高い深刻度を設定し、サーバやリソースについては中程度の深刻度。通知してもしなくても良い情報は、何も付けないなど、重み付けを取り入れました。
このアイディアは、救急救命におけるトリアージ的な手法と思っています。厳密にはトリアージとは異なり、トリアージにおける優先順位の判断のみを取り入れます。最後は、人間が状況を判断し、より細かな調査・対応を進めていくことになります。
このように監視設計にあたっては、何が致命的（クリティカル）かを考えて、トリガの重要度を調整・検討しました。結果、障害発生時の切り分けや、障害範囲の特定、復帰のチェックがスムーズに改善できたと思います。
アラートメールが来てから、ただ闇雲に慌ててメールを追いかけるのではなく、Zabbix を参照するのを最優先にします。むしろ、常に Zabbix さえ見ておけば、メールは読まなくてもいい。実際、現時点ではメールを追うより、Zabbix のトリガ画面が常に正常（何も表示されない）状態が正しいと考えるようにします。このような対応が出来たのも、Zabbix があったからでした。
蛇足ですが、オープンソースで公開されているからとはいえ、自分は無料で使えてしまったりします。ちょっとフリーライダー（ただ乗り）ぽくて、後ろめたい思いを感じています。ネットに散らばる情報は、どれも先人達の智恵のお陰で、僕はなんとか使う事ができました。せめてもの恩返しではありませんが、自分が気がついた事なども、せめて blog を通して公開させていただいています。
このように、障害を通して機能を改善する、これはまさに障害駆動運用(DDO;Disaster Driven Operation)ではないか、とも思ったのですが、お客さまにとっては冗談じゃない、ふざけんな！ですよね。大変申し訳ございませんでした。始めから色々対策をとっておけば、と悔やむことは多々あります。
一次対応の闇
さて、自分たちが一次対応も行う事にしたため、業務時間中はサブディスプレイから目が離せません。常に Zabbix のトリガが正常かどうかや、異常値がないかを見張ります。あるいは、お客さまからお問い合わせのメールが来ていないかに神経を研ぎ澄ませます。10年前の一次対応を行っていた頃は、もっとおおらかというか、放歌的だった印象があります。今は一秒足りも見逃せません。
このように運用チームはピリピリしているのですが、社内で傍から見ますと、単にイスに座っているだけに見えるかもしれません。ですが座っているとはいえ、まるで帰省ラッシュなどで混雑する高速道路を走る時の集中力・緊張感にも似たようなものではないでしょうか。
しかし、そうやって取り組んでも、結果を残せない事もあります。実際トラブルによりお客さまがサービスを解約された際に「色々と制約のあるホスティングサービス」と指摘された事もあります。正直ショックでしたし悔しかったです。それでも、頑張っていたというのは自己満足でしかなく、まるで面と向かって「お前が思うんならそうなんだろうな」と言われたように、身につまされる思い。まだまだ及ばない事が多すぎると、反省する日々です。
ただ一つだけ勘弁して欲しかったのは、まさか自分の誕生日の早朝に、障害連絡コールで叩き起こされた事です。布団から這い出て、状況チェック＆お客さまの携帯電話にエスカレーションをするという、ある種の修羅場もありました。ま、今となっては良い思い出です。
一度は仕事を辞める覚悟をした
2年前に人生を考える転機ありました。プライベートな出来事、自分の中では大きな出来事があって、仕事を続けるべきか辞めるべきか。本当に悩みました。わけが分からないよと。
結果として今の仕事を続けることができるようになりました。いろいろな方に助けられながら、今のようにサービスを形にすることが出来て感謝しています。そして、仕事を続けて良かったと、心から思っています。
でも、仕事以外の僕自身のこと、家族のことについては、正直至らなかった。出来る事なら、時間を巻き戻したいけれど、無理。もう無理なんです。
時計の針は進めることが出来ても、戻すことはできない。
時計の針を進めるには、自分の時間を作る必要。そのためには、手作業で行っている部分は自動化して時間を作らないといけないと、確信に至っています。
時系列的には、Zabbix や serverspec の導入を行う前。当時は、いかに監視精度を高めるかに重点をおいていました。考えとしては、リアルタイムに様々なデータ（metrics)を処理し、統計的手法で障害予測なりが出来ないかと。イメージとしては、緊急地震速報のサーバ／ネットワーク版です。瞬時に影響範囲を予測し、対応出来るような体制作り。
しかし、これは青写真を作る段階で、一旦ストップします。結局そんな監視システムがあったとしても、サービスが止まっては水の泡。それに、結局人間が判断するような状況は変わらない。それならば、人が監視画面に張り付くのが現実解（追加費用をかけず、体制的にすぐに取り組める）と考えたのです。
そして、サービス向上の方向性も変えました。単純な監視精度向上ではなく、時間確保の為の効率化や、サービス安定・品質向上に指向するようにしたのです。
正直、もう人間が運用や監視対応するのは限界かもしれない
僕は、SNS なりスマートフォンの登場によって、運用や監視が変わったのではなく、僕等の生活が変わったから、運用スタイルも変える必要があると感じています。
生活に密着するコンピューティングは、僕等の生活そのものを変え始めています。東京都内では、地下鉄でもスマートフォンが使えるようになってから、まだ1年もたっていません。なのに、電車内でスマートフォンを触るのは、日常の一コマになっていますよね。
今後は、スマートフォンのように、どこでもネットワークにつながる高機能コンピュータを、子ども達も持ち歩く時代。そして、低価格小型コンピュータの普及。コンピュータやネットワークが更に身近なものになろうとしています。センサが集めるデータをトリガにして、何かを行う手法が普及するのかもとか。
そういった時代に向けて、運用や監視スタイルを考える必要が出てきていると思います。単純に人間が監視をしようとしても、監視対象数・リアルタイム性・迅速な判断という点で、もう人が追いつかなくなっていないかと。ですので、よりサーバやアプリケーションについても、高い品質が求められてくるようになる。
そして、人が変に苦労する時代は終わらせなければと。
僕が本当に感じているのは、もう人間が障害に対応しているような時代じゃないなと。例えると、地下室で大きな棒を廻すイメージ。あるいは、竹槍で戦ってるような時代。もうそういう次元じゃないような気がしています。気合でシステムが廻るんだったらどんなに幸せか。
そういう意味では「いやー、昔からこの手順で運用してるんで宜しく！理由はわからないけどね」というのは、滅びる良い時期なのかなと。 自動化に任せる所は任せしまって、第三者的に（ツールで）自動化できない理由が無いものは、無くしていくのも、アリかなーと。人間はそんな暇じゃない！（と思います）。
点から面への展開といいますか。目の前の障害に神業・神速トラブルシュートしたとしても、システムとして落ちていたり、利用者に迷惑をかけては元も子もない。逆に、そこ（目の前のサーバ）で失敗しても、システム全体でカバーできていれば無問題というか。そういう視点も必要になるのかなと。
そういう事を考えたのも、ソーシャルネットワークやゲームの普及期、ホスティングという立場でありながら、お客さまに近いところで様々な経験を積ませていただいたからだと思います。
さて、そうやって今の運用スタイルを変えるにも、どうしたらいいか分からない。……そんな、モヤモヤしていた時に教えて頂いたのが Serf です。
Serf the Librator ――運用対応自動化が、進化への鍵か
こちらは先日発表したスライド「Serfが面白いと俺の中で話題にwwwwww」。
このスライドで伝えたかったのは、 運用＝Operationではなく、運用＝Logisticsに変わろうとしているのかなと、感じている事を形にしました。
日本語で”運用”と書くと、たぶん職種なり立場なりによって様々な解釈が出てくると思います。最近の流行？は”運用担当者を減らせ！”ですが、いわゆるoperation=作業という文脈かなと。確かに、ここは自動化で減らされるべきところかな。だって、人じゃ無くても出来る所はあるでしょうし。
でも、運用の仕事はたぶん無くなりません。今は仕方なく目の前のoperation(作戦)に拘っている（ように見えます）が、本当はサービス全体の安定・品質向上に力を費やすべきかな。そういう意味で、運用はoperationではなく、logistics(兵站)に進もう！とか思うわけです。
上手く言語化できないのですが、目の前の障害に対応するための技術というよりは、サービス全体の安定正なり品質を求めるための技術こそが、今後必要ではないかと。その要素技術が、自動化ではないのかなと。今は構成管理や監視の自動化ははじまりつつあります。今後は、日々の運用のうち、人間が行う必要がない作業は、どんどん自動化が進むのではないでしょうか。
ところで、serfdom の意味には、農奴や奴隷と言った意味あいがあります。そこで、僕の中ではちょっとした気がつきが。かつて、農業は肉体労働でした。ですが、機械化によって、人間は楽に多くの面積を耕したり、生産性が向上しました。どれだけ、人が両腕で田畑を耕す能力が優れていたとしても、牛馬なり、機械たるトラクターの力には適いません。
このようなイメージと、serf の語源から察する所かつ「運用担当者=serfdom」(ﾟДﾟ)ﾊｯ！ ≒基盤少女インフランジニア」という所から、現場運用の解放者たる’Serf the Liberator’というイメージがビビッときました。
本来機械が出来る Operation 的な作業は機械に任せて、人間は、品質維持の為の Logistics に力を注ぐと、みんな幸せになれるのかなと。そういう意味で、Serfというのは、運用や監視のあり方をかえるエポックポイント的な意味があると思っています。 だから”Serf the Liberator”
じゃ、人間は何をすべきか。人が人しかできないような緊急時の判断、まさにトリアージ的な障害対応（トラブルシュート）の技術なり、手法を極めていく必要があるのではと考えています。ここにこそ、運用の生きる道があるのではないでしょうか。
世界やシステムの流れは間違いなく変わっている／変わりつつあるのに、運用が変わらないというのは、もう許されないというか、時代は変わっていますよ？というのを感じる秋の夜長であります。
とか言いつつ、自分はまだ答えを持っていません。 まずは Serf を手がかりにして（ Serfが流行るかどうかは別として）、色々な方向を模索しないと、運用担当者という立場どころか、この世界（システムなりサービス）が滅んでしまう／駆逐される時代だと感じています。まぁ、精進です。。
そんな思いも込め、先日のスライド「Serfが面白いと俺の中で話題にwwwwww」に至ったわけであります。自分が正しいかどうかは、正直わからないけれども、多くの運用に携わる方に、考えていただく切っ掛けになれば、それはとってもうれしいなって
補足しておくと、「どこにいても人はつながっている」の元ネタ lain です。偏在する存在といえば、魔法少女まどか★マギカにおけるキュウベイだったりするのかなと。システムの観測者ないし行使者たる QB（インキュベーター）と、Serf が何故か被ってしまうんですよね、なぜか。結構本気に。
あるQBが倒されても、すぐ別の筐体（ QB ）が現れて会話できるのは、たぶんゴシップロトコルを使ってるんでしょうか。そういう意味で Serf は QB の原型かもしれませんよこれ、真面目に。ほんと、ほんと！
今日よりも鮮やかに
私は基本的にアニメが好きなのですが、今年は「ビビッドレッド・オペレーション」に深く感銘を受けました。前向きなヒロイン達の活躍を、毎週、心躍らせながら観たものです。シリーズの Blu-ray 全巻を買い揃えたのは何年ぶりでしょう。
ビビッドレッド・オペレーションは、迫り来る未知の敵に対して、ヒロイン達が力を合わせながら戦う物語。どんな時も、彼女たちは諦めず、仲間と友に立ち向かいます。様々なタイプの敵に対し、状況に応じて戦う姿は、なにかオペレションというか、運用の仕事に通じるものを感じました。
タイトルにある「ビビッド（VIVID）」とは「鮮やかな」という意味。ということは、ビビッド・オペレーションは鮮やかな運用？ ハッ、そういえば、運用や監視だったり、インフラ側の現場は、一見するとビジネスを支える裏方、といいますか、割と影の立場かもしれません。でも、光があるから影がある。両者の関係は切っても切り離せない存在。更に、今は鍵となる技術が色々出てきていて、運用の現場も変わり始めている、また、新しい風が吹き始めている気がします。
振り返ってみると、仕事以外の人生は、色褪せていたかな、正直。せめて、これからは、鮮やかにしてきたい。これからも、運用現場だけじゃなく、ネットワークによって世界が良くなるように、仕事なり、人生を通して貢献したいと思っています。
俺たち（運用）の戦い（未来）はこれからだっ！
完
