AWS認定ソリューションアーキテクト プロフェッショナルレベルの話

※本記事は2016年4月末の情報です。


AWS認定ソリューションアーキテクト　アソシエイトレベルが失効する。
という訳で、失効2日前に滑り込みで合格しました。
そもそもWeb上にはプロフェッショナルレベルの話が少ないので、
体験記となりますが参考になれば。

私の受験時のスペックですが、残念ながらクラウドに触るような場所に居ませんでした。
というのも、無職になっていたので。
半年ほど業務から離れていた人が受けたという状態です。

AWSについては業務に就いていた頃はある程度は追っていましたが、
業務から離れてからは、時々ニュースで見る程度。
ただ、AWS Summit Tokyoは欠かさず行ってたので、元々事例についての理解は深いです。
AWSのコンソール自体、他社クラウドとの比較で触る程度というレベルです。
受験する9か月位前に１度プロフェッショナルレベルを受けて落ちています。

今回私がやった事は至ってシンプルです。
○ 出題範囲を確認する
○ 模擬試験を解く
◎ AWS Black belt techシリーズを見る

◎ サンプル問題を解く

○が前回受験時にやった事で、◎が今回の受験でやった事です。

前回は57%で不合格でした。今回は71%で合格です。

前回と違うのは、出題範囲のAWS Black belt techシリーズを見てサンプル問題を解いただけです。

実質今回の勉強時間は4時間程度だと思います。

前回は模擬試験も受けたので結果的に10時間位勉強したと思います。

試験内容については詳しく書けないので、振り返りと感想という形で書きます。

受ける前提としては、

１．AWSの各サービスを理解して提案出来る。

２．AWSを使用したアーキテクチャが想像出来る。

３．そもそもITインフラに対しての知識がある。（特にWeb3層）

これがスタートラインだと思います。

例えば、DynamoDBを使用してどういう事が出来るのか。

下記リンクの記事を読んで、あ～なるほどね。という理解があるレベル。

http://aws.typepad.com/sajp/2014/07/games-on-amazon-dynamodb.html

こんな感じで各サービスを理解してアーキテクチャが想像出来る事。

これは１～３がしっかりと備わっていれば恐らく問題ないかと思います。

そしてここからプロフェッショナルレベルで必要だと感じた事ですが、

１．各サービスのメリット/デメリットを理解する

２．コストについて理解する

３．サービスのスタックについて理解する

の３つが備わっていれば恐らくは模擬試験も解けると思います。

各サービスのメリット/デメリットについてはBlack belt techシリーズが参考になります。

私の場合、ほんと、これ読んで受かったようなものなので。

極端な話ですが、ネットワークの部分だけ60%を切っていたのですが、

これはDirectConnectのBlack belt techシリーズを読んでいなかったからです。

とても上手くまとめられており、各サービスのコスト感、メリット/デメリットも理解できます。

一番重要なのは、「これは出来るけど、これは出来ない。」という取捨が解る事です。

これが解れば、あとはサービスをどう連携させていくかがイメージ出来るかどうかです。

例えば、下記URLの構成を見てどんな事をしているかイメージが出来る。

そんな感覚で問題ないと思います。

https://aws.amazon.com/jp/solutions/case-studies/chatwork/

プロフェッショナルレベルを受ける上で最も重要な事は「集中力」だと思います。

3時間弱という長丁場なので、かなり集中力が必要です。

80問という問題数なので、1問約2分で解く必要がありますが、

おかしい日本語の言い回しが多いので、先ず文章の読解でつまずきます。

翻訳試験あるあるなのですが、よくよく読んでみると同じ意味合いの選択肢があったり。

そんなレベルの誤訳があるので、相当集中して読解する必要があります。

前回の試験の時は睡眠時間が足りずに集中力が持ちませんでした。

今回は十分に睡眠を取り、早めに試験会場の近くに行ってBlack beltを読んでました。

サービスとして提供してそうだけど、してない。という事をおさらいで確認しました。

読解という意味だと、例えば、以下URLのサンプル問題にある内容で考えると解りやすいです。

http://media.amazonwebservices.com/jp/certification/AWS_certified_solutions_architect_professional_examsample0701_08_final.pdf

3問目が解りやすいのですが、要件が書いてありますが、

コスト効率が高いスケーラブルな環境と指定があるので、この選択肢を読む限り、

オートスケールは無いなーと直ぐ解ると思います。

この辺りは読解が必要なので、しっかりと集中出来る状態を作っておく事が重要です。

模擬試験は受けた方が良いと思います。特にブラウザで直ぐ受けられる試験なので、

場所と時を問わずに受けられます。ちなみに私が模擬試験を受けた時は33%で不合格でした。

AWSは3文字略語が多いので、模擬試験で解らない単語や略語が出てきたら、

これは調べて潰していった方が良いです。

まとめですが、これからプロフェッショナルレベルの試験を受けるにあたって、

やった方が良い事は・・・

１．出題範囲を確認する

２．Black belt techシリーズを読む

３．模擬試験を受ける

４．AWS Summit やコミュニティに参加して事例への理解を深める

５．しっかりと寝る

この５つをお勧めします。（特に1度落ちた人は５が重要だと思います・・・）

今年もAWS Summitがありますね。あの空気感は大好きです。

ちょっと試験と関係無いですけど、このコミュニティが事例をシェアし合うというのは、

とても重要だと思いますし、この2日間(エンタープライズデイも合わせると3日)は、

受講料に換算すると数十万～百万円位の価値があると思います。

私も今はIDCFクラウドのユーザーコミュニティで運営側に就いていますが、

コミュニティを立ち上げようと思ったきっかけはAWS Summitです。

NTTドコモの栄藤さんのセッションで、ドコモがDiveしたのはコミュニティがあったからという言葉。

これはとても納得させられて、IDCFクラウドや他のクラウドでも同じようにコミュニティが作れたら、

きっとDiveしてくる企業さんが増えて、結果的にノウハウが倍々で蓄積されていくんじゃないかと。

ノウハウの共有により、さらにノウハウが増えていくという素晴らしい環境が生まれたら嬉しいですね。

AWSという選択肢は勿論ですが、他のクラウドの選択肢も考える事で、

よりよいクラウドアーキテクチャが生まれていくと思いますので、興味がある方は御気軽にご参加下さい。

■IDCFクラウドUG

東京：https://idcfcloudug.doorkeeper.jp/

つくば：https://idcfugtkb.doorkeeper.jp/

大阪：https://idcfugosaka.doorkeeper.jp/

ちょっと話がそれましたね。

AWS Summit Tokyoについては当日参加でも並べば見れるセッションが多々ありますので、

もし試験を受けようと考えている方がいらっしゃいましたら、是非参加する事をお勧めします。

それでは。

IT運用事故が激減する7原則～対応3原則編～

IT運用を10年以上もやっていれば、それはそれは大きな事故を起こす事もあります。
システムトラブルだけではありません。お客様との関係性が起因するクレーム等もあります。
事故自慢は置いといて、事故を振り返りやすくして、事故を激減させる７原則があります。
先に言っておきますが、この7原則は私が作ったものではなく、
サービス業界にて既にある幾つかのルールをIT運用に適用したものです。
対応における3原則は「愛されるサービス」という本に殆ど書いてありますので、気になる方は一読をお勧めします。とても素晴らしい本です。
また行動における4原則はディズニーランドのホスピタリティ系の資料を読むと出てくるので直ぐ探せると思います。

対応3原則には株式会社HUGE代表である新川義弘さんの考え方です。
新川さんはover30世代ならば覚えているかもしれませんが、
ブッシュ大統領・小泉首相(当時)が居酒屋会談をしましたよね。
あの給仕をされた方で、サービスの神様と呼ばれている方です。
実践すれば確実に効果が解りますので、是非愛されるサービスを読んでみて下さい。
お気付きかと思いますが、このブログの題名もこの本から取ったものです。

行動4原則にはオリエンタルランドのSCSEという行動規範を採用しました。
オリエンタルランドは言わずと知れた東京ディズニーランドの運営会社です。
最近、ブラックだのなんだのと言われていますが、安全への考え方はトップレベルです。
実際にアルバイトをしていたので、SCSEについてはよく理解していました。

上記対応3原則と行動4原則を合わせる事で、愛される運用・監視を実現し、
振り返りを効果的に行い、事故を減らします。
前置きはこの位にして、今回は対応3原則から書いていきます。

-----------

対応3原則はお客様との対応をする為のマインドを説いている。
以前、突き抜けるサービスで顧客と対等に接してプロセスを共有するという事を
書いた。対応3原則についてはそれを実現する術に近い。

対応3原則は
　・リコグニション（顧客認知）
　・アンティシペイション（事前察知）
　・オペレーション（運営）
の3点から成り立っている。順を追って確認していく。

リコグニション（顧客認知）とは、読んで字の如く顧客の事を知るという事だ。
レストランで例えてみよう。チェーン店では一見接客(いちげんせっきゃく)が多い。
それは誰にも分け隔てなく同様のサービスを提供する為の術だ。
あなたは可でもなく不可でもないサービス。期待通りのサービスを提供される。
特に不満足は無い。そういうサービスを提供していると解っているからだ。
しかし、次に来店した時にこういう反応がかえってきたらどうだろうか。
「○○さま、先日はご来店ありがとうございました。」
きっと、「えっ！」と驚くだろう。この対応は期待していなかったからだ。
自分のことを覚えてくれていた事で特別扱いされたような気持ちになる。
あなたは一気にこの店員のファンになるだろう。そしてお店に通うようになる。
俗に言う常連という人達はこの気持ちに近い筈だ。

「○○さま、ブロッコリーは抜きにいたしますか？」
なんて聞かれたらどうだろう。前回、確かにブロッコリーを残した！
自分の嫌いな食べ物を理解してくれているのか！と嬉しくなるかもしれない。
ただ、チェーン店でここまでされたらストーカーではないだろうか。と勘ぐってしまい、
若干引いてしまうか、怖いから行かないようにしようとも思うかもしれないが・・・。
予約を入れてドレスコードがあって給仕が居るようなレストランであれば、
これぐらいの接客を見せてくれる可能性は十分にある。
顧客の名前は勿論、好き嫌い、記念日も覚えている。
出来る給仕は他愛も無い会話からその人の趣味嗜好まで把握して覚えている。
野球好きであれば贔屓のチームの試合の話をしたり。
これは動向も把握していなければならない。
例えばイチローがマーリンズに移籍したという情報も知っていなければ話せない。
話題を切り出す為には、相手のことを理解しているだけではなく、
それを生かす為に常に努力する事が重要だ。
この会話が成立した時にあなたは店員の事がもっと好きになるだろう。
これがリコグニションだ。

この考え方はIT運用でも同じ事が言える。
相手のコンテンツを徹底的に理解する。そして好きになる事。
例えばゲームの案件であれば、必ずリリースされたゲームはインストールして実施する。
実際にどのタイミングで課金されるのか、また負荷が掛かっていくのか。
そういう部分を知らなければ提案も出来ない。
Webサイトであればtwitter等、バズりやすいSNSをウォッチしておいたり、
常にアンテナを張ってニュースに敏感になるようにしなければならない。
相手を理解するということは”相手を理解しよう”と努力する事から始まるのだから。
当たり前のようだが、実施できているかを当てはめて考えてみると良いだろう。
IT運用エンジニアはコードを書いたり、ミドルウェアをチューニングしたり、
対顧客に関する意識がどうしても欠如しがちである。
アラートメールに書いてある事は解るが、アラートメールの先にあるものが見えづらい。
運用は"何も起きないのが当たり前"の世界の為、常に顧客が見てるものを一緒に意識すると、
プロセスを共有出来、リコグニションも上手く浸透していく筈だ。

次にアンティシペイション。

アンティシペイション（事前察知）とは、顧客がやろうとする事を事前に察知する事。
居酒屋で例えるととても解りやすい。
　～あなたは今、お酒を飲んでいる。お酒をおかわりしたい。～
あなたはどのタイミングで店員を呼ぶか。
１．グラスが空いてから呼ぶ
２．グラスが空になる前にある程度残しておいて呼ぶ
基本的には１の人が多いのではないだろうか。
１の人で、店員が持ってくるのが遅い店では２に変更する。という人が多い筈。

飲み屋によく行くという方は、こういう店は無かっただろうか
・グラスが空きそうになると、店員が「次の御飲物お持ちいたしますか？」と聞いてくる。
空になってから聞かれるのではなく、丁度飲み干した位のタイミングで持ってくる。
きっとあなたはこう思うだろう。
（この店は、接客が行き届いているなぁ。）
接客が行き届いている店では気持ちが良い。
食事に集中が出来たり、話に集中出来たり、自分がやりたい事をする為の条件が整う。
そしてあなたは（また、次も来よう。）ときっと思うだろう。リピーターの出来上がり。

アンティシペイションはこのように顧客が事前に行う事を予測して行動する事。
これはITでも言える。究極的に自動化してしまったのがオートスケールと考えれば解りやすい。
最初はお伺い、御用聞きから始まる。
「最近、負荷が高くなってきましたね。何かイベントとかやっていますか？」
ここでイベントの情報を得たとしよう。きっとあなたは何らかの策を講じるだろう。
この策をあなたは隠れてコソコソとやってはいけない。
あくまで内容をシェアする。そしてプロセスを共有する必要がある。
そうすると相手は次のイベントの時には先に相談してくれるようになるだろう。

事前察知する為には、顧客の売り上げや業界規模も把握する必要がある。
売り上げによってはシステムのシュリンクを提案したりすることも必要だろう。
古いミドルウェアを使用していて、業界の標準から遅れているようであれば、
ミドルウェアの変更やバージョンアップの提案もしていく必要がある。

気付いた方も居ると思うが、提案する材料を集めるのはリコグニションが必要だ。
顧客認知をして事前察知力を高めていく。この流れが基本である。
リコグニションとアンティシペイションを発揮してオペレーションに繋げていく。

このオペレーション（運営）がとても重要。ここからが特に重要な話となる。
運営とは飲食店で言えば、お店を回す力を指す。
滞りなく料理や飲み物が提供出来、ここちよい空間を提供出来る事。
これを実現するには顧客を知る事と、事前に察知する力が必要だ。
ただし注意しておく事がある。"あくまでユーザとは対等"という前提を無くさない事だ。

飲食店で酔って騒いでいる、俗に言う悪いお酒になっているお客が居たとする。
周りのお客にも絡んでいるようで、みんな苦笑い。
その酔って騒いでる客は常連客だ。金払いもとてもいい。
あなたが店員であったらどういう対応を取るか？
きっとそのお客に「もう少し静かに御飲み頂けますか？」などと言うのではないか。
しかしながら、そのお客が注意を聞かずに騒いでいたらどうするか。
「これ以上騒がれますと他のお客様にも迷惑になりますので、御引き取り頂きます。」
などと申し伝えるのではないかと思うが、問題はここから先が重要。
あなたは本気でその常連を帰れといって店の外に連れて出せるだろうか？

一見さんお断りという京都の料亭等は、コンセプトを知らないと満足いくサービスが
提供出来なかったり、コンセプトにマッチングしない方が同じ空間に居るだけで、
馴染みの方へのホスピタリティに影響し、お互い悪影響が出てしまう恐れがある。
だから一見さんお断りというのがあるんだという話を聞いたことがある。
決して高飛車で言っている訳ではない。高級店はドレスコードが厳しかったり、
敷居が高いのにはそれなりの理由がある。
顧客をコントロールする力もオペレーションの１つという事だ。

ユーザが解約をおどし文句に理不尽な事を言ってくる事があると思う。
また、解約ではないにしろ、何らかの圧力をかけてきたりというのはよくある話だと思う。

ここでもう1度質問を考えてみて欲しい。
あなたは本気でその常連を帰れといって店の外に連れて出せるだろうか？

この時点で対等であるというバランスが崩れているので2択で考える。
バランスが崩れた時点でユーザではなくなっているのだから、
対等という意識をもってもらえるように教育しなおすか、それか解約してもらうかの2択になる。

ただし勘違いしないでほしい。このケースの殆どがお客が悪いという事例ではないのだ。
導入の際に問題点があったり、日々の運用で上下関係を作ってしまったり。
色々な理由があっておきてしまった事であり、オペレーションの問題。
要するにユーザコントロールが出来ていない、もしくは出来ない環境下だった。という事だ。

前述の飲み過ぎた客、更に常連というキーワードであれば、
どれくらいお酒が強いかや、何か深酒してしまうような出来事が無いかという顧客認知と、
飲み過ぎて悪い酒になっていないかというような事前察知があれば防げたのではないか。
あなたは常連客をユーザのままで居て頂くことが出来るという話になる。

しかしながら多くの場合は、バランスが崩れた後も顧客だからという理由で、
問題を曖昧にしたり、目をつぶってしまったりしているのではないだろうか。
きっと振り返る事もせずに、現場は疲弊し、ユーザもシュリンクしていき解約になっていくだろう。
そういう経験をしたこともあるのではないだろうか。
曖昧にし続ける場合は自社オペレーションから切り離す等の覚悟が必要だ。

オペレーションで重要なのはこの振り返る事。
例えば導入の際にお金が良いから納得性が低いまま強引に取ってきた。等が無かっただろうか。
日々の運用で3営業日かかる仕事をasapという4文字で緊急扱いにして対応してなかっただろうか。
これを指摘したらきっとこういうかもしれない。
「お客様が望んでいるから仕方ないじゃないか。」と。
お客様が望む事が幸せではない。愛される運用とは程遠く、満足度も上がらない。
それは、お客様が望む事＝当然、期待している事なのだから一見接客と変わらないのである。
要するに顧客認知、事前察知、そしてユーザとの対話や説明を放棄しているだけなのだ。

何かクレームやユーザとの関係性に関する事故が発生した際には、
是非この対応３原則を念頭に置いて運営について振り返ってみては如何だろうか。
私自身、まだまだ出来ていない身ながらもこの対応3原則で顧客対応を振り返ると、
必ず改善点が見つかる。伸びしろは常にあるという前提で、どうか試してみて欲しい。

----------------

ちょっと今回は1話で長く書きすぎたのであとがきを入れます。

この対応３原則の重要性をご理解頂けたでしょうか。
続きの行動4原則は、具体的な行動についての考え方なので解りやすいと思いますが、
対応3原則は例え話も飲食店が多いので解り辛かったらすみません。

振り返りを効果的に行うには全員が同じマインドを共有しておく必要があります。
私がチームビルディングする際には常に対応3原則を意識するようにし、
メンバーには必ず覚えてもらっています。その為、日常のたとえをする事が多くなってます。
（もっとも出来ているとは口が裂けても言えないような状況ですが・・・orz）

私は業務中でも顧客が提供しているゲームは普通にやって良いと言っています。
むしろ奨励しているという方が正しいかもしれません。
また、顧客が良く使うツールは触るように指示をしています。
これは顧客認知の為の努力と考えている為です。
業務中にゲームをするなんてけしからん！と思う方も勿論いますし、メンバーにもいました。
そのゲームをエンドユーザがやる事によって我々の仕事があるにも関わらず・・・です。

なかなか意識の共有は難しいですね。
まだまだ納得出来るような運用は実現出来ていませんが、
この対応3原則を使って、すこしづつ運用における環境が変わっていけばいいな。
と、お客様からのお叱りのメールを見ながら思う次第です。

長文を御読み頂きありがとうございました。

突き抜けるサービスという考え方

ITというよりも、サービスに対する私的感覚。
何かサービスを考えるときは、常にリコーの田村氏の講演内容を思い浮かべるようにしている。
http://www.icpe.or.jp/icpe/icpe_1/3400/
今回の内容は殆ど上記に記載されています。なにせ、私のバイブルのような講演なので。

新しいサービスを生み出すときに指標にするのが、ナンバーワン企業の法則。
オペレーショナルエクセレンスとプロダクトイノベーション、カスタマーインテマシーからなる。
優秀な企業になるためには、どれか１つを選択する必要があるという考え方。

殆どの会社はカスタマーインテマシーを選択している。
突き抜けている会社はオペレーショナルエクセレンスやプロダクトイノベーションを選択する事が多い。

例えばユニクロ。
オペレーショナルエクセレンスを実現して、フリースやジーンズで価格破壊を起こした。
当時は所謂”ユニバレ”という言葉が生まれ、ユニクロを着ていることがバレるのは、
恥じというような状態だった。しかし、ユーザは買った。買い続けた。

そうなると、あれ？これってありなの？という事で他のメーカーも、
激安衣料品に参入してきた。続々と参入してきた。
そして、この分野では一気に競争過多になる。

突き抜ける会社が出るとレッドオーシャンになる。
これはブルーオーシャン戦略から見ても明らか。

ユニクロはここで負けなかった。とても強かった。
シンプルを着こなすという売り出し方に成功。
広告もシンプルな着こなしを意外な人がやっているというところでとても注目された。
ユニT等に代表されるように、"時代の先取り"という企業になった。
新商品開発ではインナーに目をつけ、ヒートテックを開発した。
これは各社がまた真似をした。しかし他社は所詮2番煎じ。
要するに猿真似であり、ユニクロの影はもはや拭えない。
オペレーショナルエクセレンスではなく、プロダクトイノベーションへスイッチに成功。

ここで考えると、やはり最強はプロダクトイノベーションという話になる。
要するにブランド化なのである。

カスタマーインテマシーを追求する企業をよく見かける。
しかし、これは果たして本当に追求出来ているのか。

実は日本人はすでにサービス精神というのが備わっている。
お客様は神さまです。という感覚は江戸時代から続いている。
顧客第一主義は吉宗の時代から流れている日本人の心。
石田梅岩が提唱した内容は"おもてなし"という大事な文化となっている。

ゲルマン民族はホストがゲストを迎え入れるという"ホスピタリティ"を持っている。
よく、同じ考え方をする人が居るが、ホスピタリティとサービスでは性質が違う。
サービスというのは語源はサーバントであり、召使・奴隷なのである。
これは、お客様は神様ですという考え方。お客様自身も自分が主人だと思ってしまう。
従って不条理な値下げ要求をやったり、怒鳴り散らしたりという自体が発生する。
市役所や家電量販店でよくみるのは、サービスとして考えている人が多いから。
結果的に顧客の立場が上になってしまうのである。

ホスピタリティの語源はホストであり、主人が旅人を歓迎するところから来ている。
ホスピス等の言葉についても同様であり、迎え入れるという意味合いがある。
この場合は顧客は対等、むしろホスト側の方が強い。
ディズニーランドで考えると解り易い。
実はディズニーランドというのはホストが圧倒的に強い。
強制的に退場させる権限を持っている。夢と魔法の王国に合わない人は徹底排除。
園内で弁当を食べたり、コンビニのおにぎりを頬張っていたら大変だ。
直ぐにランチエリアにつれていかれてしまうだろう。
しかし、対等な立場で楽しむ人に対しては最高のパフォーマンスをもって迎え入れる。
これはとても簡単な話で、自分の家に入ってきてくれるお客さんに対して、
ルールは守れよ、と。そうしないと他の客も楽しめなくなるだろ、と。
完全にホストの方が強い。これがホスピタリティ。

ホスピタリティとサービスについては別の機会に触れるとして、
とにかくサービスとホスピタリティは違うと認識して欲しい。
そのうえで、"おもてなし"を考えた場合、何なのか。
日本人は農耕民族であり、おもてなしの意味合いはホスピタリティの文化とは少し違う。
おもてなしは基本的にお客様を満足させようという気持ちは、ホスピタリティと変わらない。
迎え入れるという主人の立場、対等に振舞うというのも変わらないが、
ルールを守れない人に対しても、奉仕の気持ちで接する。
そして、しっかりと教育を行うのもおもてなしの特徴なのである。
ある程度、この部分に日本人は美意識を感じている。そこから外れる物はノイズでしかない。
なので、おもてなしをしてもらえると考えるところでは、それ相応の対応をする。
郷に入っては郷に従え。なのである。

おもてなしをしてもらえないと感じるところではしない。
お客様は神様です。そういう扱いをしてもらえるところでもしない。
なぜなら、そこはサービス、召使いを扱き使う考え方なのだから。
この考えが通る会社で果たしてカスタマーインテマシーが実現出来るか。
カスタマーインテマシーでは顧客とプロセスを共有する事が重要になる。
顧客と全てのプロセスを共有するには上下関係を作ってしまうところは難しい。
ディズニーランドの例では、顧客はプロセスを共有し楽しむことを目的としている。
その為に必要な事は例えゲストであっても強制排除対象とするのである。
この決断を出来る企業はなかなか存在しない。突き抜けるのは難しい。

役所では税金を納めてやってるんだ！という強い気持ち。
また、働いてる人間は公僕なんだ！というような上から目線がある。
そして、役所の人間もそれを受け入れてしまう。もしくはそんな事は無いと態度に出してしまう。
それが一層に不愉快さを増してしまい、客の神様目線を増長させてしまう。
そういうサービスを提供してしまう場合が多い。
ここでおもてなしを実施すると、また別の結果が生まれるか？
答えは、yes。ただし、これにはとても長い時間が掛かる。
なぜなら来る人間を"教育"しなければならないからだ。
この役所は普通とはちょっと違うぞ？　そう思わせなければならない。
そこから、職員もちょっと違うぞ？あれ？これは、郷に入っては郷に従わなければ。
そして、自身の神様目線はノイズになっていく。
突き抜けるサービスは常に対等の立場でお客様と接している。

今、注目しているクラウドで新IDCFクラウドがある。
500円の1コインクラウドをリリースした。
なんちゃってクラウドではない。ちゃんとしたAPIもかねそろえたサービスだ。
AWSのmicro相当のサービスが500円で1ヶ月使えてしまう。
これは前述のユニクロの時と同じイメージを持てる。
そして間髪いれずに新しいサービスがリリースされていく。
取り組みも「尖っていく」というマインドの元で動いているのでブレにくい。
ここでいうブレというのは、みんなでみかんを取りにいこうと言っているのに、
きゅうりを取ってくるようなことを言う。
りんご位だったら同じ果物で許せるが、さすがに野菜は違うだろ。というイメージ。
確実に伸びる筈（大きな事故が無ければだが）なので、新サービスに期待している。
まだまだこれからなものの、国産クラウドで最も注目されるクラウドになる筈。

このように突き抜けるサービスは努力しなければならない。
500円にするのにもなみなみならぬ努力があったことを想像できる。
他社より2割安い、ないし3割安い。これはオペレーショナルエクセレンスではない。
単なる安売りであり、しっかりと考え抜いた結果ではなく、
とりあえず時代に合わせて安くしたというケースが多い。
この場合の多くは無理な価格設定をしたことにより破綻する。
もしくは、しっかりと考えた企業に圧倒的大差で抜かれていく。

1人で突き抜けるサービスを提供するのは難しくない。
ただこれは自己満足の域を脱しない。
会社として提供する場合はメンバーの協力が必要になる。
メンバーを信じて任せる。これはとても重要な要素と考えている。
現場力の無い会社では、この委譲が上手くできてないことが多い。
その為、ローンチまでに時間が掛かる。その間に時代に追い越されてしまう。
スピードは突き抜けるサービスには絶対に必要な要素。


さて、突き抜けるサービスについてまとめてみた。
まだまだver1な訳だが残念ながら私自身が突き抜けるサービスをローンチしたことが無い。
自戒も含めて書いたことをしっかりと考えながら、
突き抜けるサービスを提供出来るチームを育てていきたいと思う。

2015年に思う事

あけましておめでとうございます。

今年も宜しくお願い致します。

2014年は運用自動化元年というお話を書きました。

遠からず、その動きは各所で見られた1年でしたが、

未だマインドという部分で停滞しているところが多いように感じました。

今年は思想から行動に移って本格的な運用オペレータの淘汰が始まると思います。

それでは今年はどんな年になるでしょうか。

2015年はコンテナ運用元年になると考えています。

コンテナというと、私はOpenVZやVirtuozzoのイメージが強く、

VPSのような感じであまり良いイメージがありません。

また、ハイパーバイザー型のようにサーバをまるっと仮想化した方が、

私のようなインフラエンジニアはやり易いように思えて、どうしてもコンテナ型は敬遠します。

コンテナ型はカーネル共有型になる為、どうしても向き不向きが出ます。

PostgreSQLやOracleのようなデータベースには向いていません。

またTCP周りのチューニングも難しくなり、アクセス数が膨大なサイトは最適化が難しくなります。

これは私が2014年まで普通に考えていたことです。

多くのインフラエンジニアはそう考えていたと思います。

クラウドが当たり前の時代となりました。

2012年のAWSサミットはホテル日航東京で2部屋で行っていました。

コイニーさんとかがStartupコンテストで登壇していたのを鮮明に覚えています。

丁度、ビッグデータというバズワードが出始めた頃です。

その頃のセッションではビッグデータをいかにストアするかという内容でした。

redshiftも出始めでどう使うのか。DWHを再考するようなイメージだったと思います。

去年は奇しくもマイクロソフトと同じ高輪プリンス。

ビッグデータのキーワードは勿論流行りのキーワードですが、大きく内容が違っていました。

いかにストアするかから、いかに分析するかという内容に変わってました。

リアルタイムに分析して提供するか。adtechが牽引している技術です。

それに伴ってAWSからはKinesisがリリースされました。

この間、たった2年です。

たった2年でビッグデータのストアをいかにするかという話をしていたのが、

リアルタイムでストリーミング解析をする為にどうすればいいかという次元になりました。

話を戻しましょう。

クラウドの「捨てる」というインフラ運用方針もやっと頭の固い人達がついてきました。

ミドルウェアを捨てるという考え方でいくと、ハイパーバイザー型よりかは、

コンテナ型の方がやり易いという話になります。

カーネルに依存するようなミドルはRDS等でPaaSとして利用します。
こうなるとハイパーバイザーでなければならない理由もなくなってきます。

ハイパーバイザーかどうかは使用者側はパブリッククラウド上ではあまり関係ないため、

コストが安くなり、更にlaunchの時間が短くなる。更に柔軟な設計が可能になり、

複数のサーバをスタックして考えるようになる。

要するにCoreOSに代表されるコンテナ管理を前提とした考え方が浸透する。

そんな1年になるんじゃないかなと思っています。

CoreOSはDockerから卒業を果たし、Rocketを打って出ました。

AWSもコンテナ型のサポートサービスを発表しました。

今年は加速するのに十分な要素が揃ってます。

コンテナのミドルウェア分散設計の方法をしっかりと抑えたいと考えています。

今年もよろしくお願いします。

私達がISUCON4の予選で失格した"たった１つ"の理由

ISUCON4にチームhogehogeとして予選1日目に参加してきました！

で、前置きはどうでも良いから何やったのか教えろという早漏君は、
ここまで飛んでしまえばいいさ！

失格した理由だけが知りたいというくれくれ君は、
ここまで飛んでしまえばいいさ！

さて。これ、本選の予習をする予定だった時間を使って書いてみたら、
凄い長文になってしまって、削除しようと思ったけど溢れ出す煮汁の如く
言葉が出てきたので、これは言霊に失礼だという事で削除しませんでした。
きっと読むの5分位かかりますよ。・・・きっと。

チームhogehogeは全員違う会社に所属していて、仕事の案件で知り合ったり
して参加した何ともTHE社会人みたいなチームです。
hoge1とK氏と私の3人で参加しました。

既にblogで皆さんが報告されているのを見る限り、

（´-`）.｡oO（みんなレベルたけぇ・・・）

って感じで、我々がやった事って全然先を行くかっちょえー感じでもなく、
ふーん、そうなのー的なレベルだし、それなら業務でやってるよね？的なので、
全然もう読む価値すらないかもしれませんが、
まぁ、暇だし付き合ってやってもいいよ？的な方がいらっしゃるんじゃないか！？
と、勝手に思ったので、もうそれならと読み物として充実させてやろうと、
文系エンジニアの実力をみせてやるぜ！的なノリで書きはじめていたら、
いやに長文になって、これ暇人じゃないと読めない。って感じなので、
ビスコでも食しながらレッドブル片手に現実逃避の御伴に読んでくれたらいいと思います。

で、結果は予選失格！な訳なのですが、まぁそれについても色々なドラマがあり、
ドラスティックな変化を執行していた訳ではないんですが、それはそれで
小規模な変化を色々と行った訳で、じゃー、なんなのさ。って言われると、
もう何なのかよく解らないんですが、強いて言えば、「楽しかった」って感じ。

本選に出れなかったんですが、本選の日の予定は勿論空けていたので、
「ヒカリエを見上げながら敗者の反省会という名の飲み会」
でも開いて惨めさを染み込ませて、
次回は絶対に本選に行ってやるという気持ちを高めようかと思います。
是非一緒に惨めさを染み込ませたいという方がいらっしゃれば
@taka3110_pcc までご連絡ください。

前置きはこの辺にして、
我々が選択した言語はみんな大好きPHPです。
perlかphpの2択でしたが、業務で慣れてるphpを選択しました。

で、色々チューニングした結果、
最高で38000、最終的な提出スコアは36500程度
でした。

予選1日目は、いろいろあれな事が発生したので、修正込で自己計測だと38000位でした。
惨敗かと思ってたら、意外にギリギリのスコアだったようで。まぁ、失格な訳ですが。



では、当日のドラマをどうぞ。



自社の会議室を借りれるという事で、皆さんにお越し頂きました。
会議室にhoge1、K氏と私の3人がお酒以外で初めて集まりました。

まずやった事。

・100万円の使い道を決める。
まず、これが大事。これを決めないとやる気が起きないという事で、
とりあえず、30万を分割し、残りの10万で祝勝会という王道パターンに決定。
決まった後は、やるぞやるぞコールです。

・コミュニケーションツールを決める
みんなアカウントを持っているという事でChatworkに即決定です。
といっても、今回は口頭と白板やモニタでのコミュニケーションが主だったので、
使用用途としては画像やURLのシェアと「コピペして欲しいコマンドを貼る」程度でした。

・コードやコンフィグの管理方針を決める
gitとかやるよりこの規模ならrsyncすればよくね？という発想で全員一致。
マスターのインスタンスと各人のインスタンスを作り、声を掛けながらマージしていくやり方に。

役割分担としては、
K氏      コード全般解析やチューニング
hoge1   インフラ回りのチューニング
自分     お茶くみ
という感じです。

お茶くみとして先ずやった仕事としては、
・お茶を配る
・お菓子を配る
・モニタや白板等、会議室の準備をする
って感じです。

一応、一番年上なんですけどねっ！
始まる前からもうあれです。あ、このメンツなら俺、戦力外やなと。
もう、K氏もhoge1も各社の中核を担う素晴らしいエンジニア達なんで！
とりあえず、会議室の設営やモニタの準備等をやらせて頂きました！
ひゃっふぅぅぅぅぅ！これで100万もらえるなんてすばらしいイベントやっ！
もう住宅ローンに回して家族からも「パパ素敵！」的な感じの祝福があるだろう！
って思ってて、この時までは勝つ自信がありました。

10:15くらいになったところでスタート。
ベンチを走らせたところ3位になりました。
ここからゴリゴリとK氏がコード全般の解析を始めます。

hoge1もゴリゴリとインフラを触り始めており、私は遠い目をしてました。
追い付くべくphp変更にあたってrubyのプロセスが落ちない等の紆余曲折を経て、
なんとかphpに変更完了。

と、この調子だとちょっとした小説になりそうなので、ダイジェストでどうぞ。


※赤字は目に見えて効果があったものです。

方針としては、大きな変更は1チャンスというイメージ。
CPUが全く使えていないのでCPUを効率的に使う為の設定、
並列処理を上げるチューニングへと大枠の方針決定。
また、memoryが大量に余っているので、I/Owaitを無くして
より効率よく処理させる方針に。

構成はphpの最初に入っていた構成のままです。
nginx --> php-fpm(2インスタンス) --> mysql

簡単に効果があった順に書くと
・MySQLのindex変更
・カーネルチューニング
・オンメモリ化（セッション含む）
・不要モジュールの削除
というような感じでしょうか。
MySQLのindexを変更する事によって効率よくCPUを消費出来るようになり、
phpやベンチに回せるようになって処理速度が向上。
カーネルが追いつかなくなった為にカーネルのチューニングを実施。
残っているI/Oを全てメモリに行くようにして、phpの重い処理を削除。
・・・振り返ると普段どおりの事をやった感じです。

本来はここから色々変更するという形になっていくと思うのですが、
そこまでは今回は手が回りませんでした。

という訳で、足取りを詳細に書いてみました。

---

Start～15:00

[自分がやった事]
・インフラのボトルネック調査
 dstatをインストールしてdstat / vmstat / topでボトルネックを確認しました。
 と言っても、MySQLが使うCPUが目立ちすぎていたので直ぐに解りましたが。。

・オンメモリ化（結果的に採用）
 一番最初にこれに取り組んだが殆ど変わらなかった為、一旦不採用にしました。
 ⇒最後に劇的な変化がありました。

・mysqlの設定チューニング（採用）
 mysqlの設定は各種bufferサイズを上げたのと、
 tmp/cache系の設定をmysql_tunerの情報を参考に入れました。
 あとはinnodbのコンカレンシーをセット。

・phpの再インストール（不採用）
 ちょっとスコアが上がったが、余り意味が無くバグが増えるのもあれなので見送り。
 　※configureオプションを見直してしっかりかえてれば・・・と後悔。

・index等を静的化（不採用）
 login等の処理でエラー多発。DOM構造を変えちゃうかも？という事で見送り。

・MySQLのアップデート（不採用）
 5.6に変更しましたがtimedateの問題でクエリを修正した結果、逆に遅くなりました。


[チームメンバーがやってたっぽい事]
・ソースコードから仕様の把握
 処理遷移を全員でシェア

・ボトルネックの洗い出し
 SQLがポイントという話に。indexの見直しを開始。

・MySQL index 作成（採用）
 indexを貼り換えたり適切なものにしていく事で劇的に変化。


[この時の感覚]
 15時の段階でindexの効果が目に見えて確認出来ており、
 徐々にスコアアップし、10000超え。
 しかし、周りのスコアがもの凄いアップしてました。
 一気に上がってるチームも居たので、恐らくコードとか全部変えてるんだろうと。
 （この予測はのちのブログを見る限り、合っていたようです）
 とりあえず、出来るところまでやろうと励まし合いながら進めました。

---

～17:00

[自分がやった事]
・APCuのインストール（不採用）
 ソースコンパイルでインストール。不採用理由は後述。

・nginxでcache（不採用）
 適当なキャッシュ設定だったので逆に下がった。
 ※こちらもしっかりと設定出来てれば、2000位のアップが見込めたので後悔。

・niceの調整（不採用）
 mysql、ベンチマーク、nginx、php-fpmそれぞれのパターンを試したがイマイチ。


[チームメンバーがやってたっぽい事]
・カーネルチューニング（採用）
 tcp session timeout設定、port range 拡張、ulimit -n 設定などなど、
 tcp周りとファイルディスクリプタ不足のエラー解消

・php-fpm 多重起動（採用）
 より並列処理させる為に、ポートを変更してもう１つphp-fpmを起動

・php date 変更（採用）
 phpのdateを設定

・APCの代わりに/dev/shmにファイルおいてみた（不採用）
 デフォルト状態の時間と変わらず

・APCで検索結果キャッシュ（不採用）
 SQL実行が高速化したためオーバヘッドが多く意味なし

・検索結果をRadisにキャッシュを検討（不採用）
 DBからの整合性がとれない+時間が無い為断念
 ※ここに早めに着手する決断が出来ていればと後悔。

[この時の感覚]
 この段階で既に詰めにかからなければいけなかったのですが、
 試していた事に対するバグ取りが結構時間が掛かるという事で、
 デフォルトのミドル構成で勝負する事を決定。
 カーネルチューニングで徐々にスコアは上がりますが、
 周りのチームのようにスコアがなかなか上がらず、半ばあきらめムードに。

---

～17:50

[自分がやった事]
・xdebug削除（採用）
 不要なモジュールの削除という事でxdebugを削除。

・カーネルチューニングにプラス（採用）
 net.ipv4.tcp_syncookies = 0を追加

・nginxとphp-fpmの通信をunix socketに変更（不採用）
 ファイルディスクリプタが追いつかない状態になり断念。
 ※ここをクリアしていれば結構増えたかもと少し手を付けるのが遅れたのを後悔



[チームメンバーがやってたっぽい事]
・nginx backend との keepalived 60（採用）
 nginxとphp-fpmのkeepaliveを設定して接続コストを少しでも減らそうと。

・log出力停止（採用）
 全プロセスのログ出力を停止してI/Oを極限まで削減

・セッション、MySQLデータのオンメモリ化（採用）
 /tmpに吐かれていたセッションファイルとMySQLのデータを/dev/shmに変更
 Diskへのアクセスをほぼ無くし、I/Owaitを0に。


[この時の感覚]
 残り45分くらいにしてセッションのオンメモリ化とxdebugの削除で、
 何とか37000台まで上がる事が出来て最後まで戦える状態に。
 ただ、なかなかその他の施策が上手くいかず、決め手に欠けており、
 焦りばかりが進むような状態でした。

---

～18:00

35000～38000で結構振り幅があった為、願いを込めながらベンチマーク連投。
結果的に値が下がってフィニッシュ orz


今回のチューニングを通して気付いたのが、
・チューニング仕きってから始めてI/O勝負になる。
・MySQLがCPUゴリゴリ使ってる場合は、indexの貼り方等、クエリ確認を優先
という感じでしょうか。
真っ先にI/Oとか色々弄ってたんですが、indexとかそっちをチューニングした
後じゃないと、効果が見えてきませんでした。
インフラ回りをガッツリいじる前にやる事あるんじゃないの？というのが教訓。

---

で、1日目だけにあった終了後のイベントに突入
～18:30
終わってからworkloadに盛り上がっているのに気付き、自分達も試したところ、

いやああああああああああああああっていう数字が。

workloadを600にしたところ、failも少なく234173。
9分程度っで完了しました。

この瞬間、完全に敗北を覚悟。
「もう、酒飲もう！　もうね。。飲もう！」
って事で、このまま新宿めだかに場所を移して反省会に突入。

本来であれば、workloadの恩恵を真っ先に受けるべき戦略だったのに、
このバグに気付かなかったのは我々の完全なミスでした。
1分で終わるだろうという勝手な憶測によりworkloadを10～30位で確認してました。
12が丁度良かったので、これをセットして報告をしましたが、並列処理を考えて
チューニングしたので、100とか桁を変えて確認しても良かった筈。完全な思い込みです。


負け・・・。負け・・・。圧倒的・・・負け！！！！


というカイジのナレーションが私の頭をよぎっていました。

ただ、これだといかに負荷を掛けるかという、負荷コンテストになるのでは？
「これ、ISUCONじゃなくてIFUCONやんけ。」という話が出た位のタイミングで、
チャットルームを覗いていたところ、運営様よりお知らせが。

ベンチマークソフトをアップデートしてバグを改修したうえで、
再計測をし更に3枠追加します！との事。

いやー、これ当日も良いジャッジだと思いましたが、
後日確認してみて改めて物凄いジャッジだと思いました。
順位を推測しながら皆さんのブログを確認していたら、
プラス3組ってものすごい絶妙な数字で、
workloadで勝ち上がった人達の分追加されているイメージなのかなと。
それを当日、あのタイミングでジャッジしたのは運営さん凄いなと。

題材も、これ弄るとこそんな無いのでは？という感じでしたが、
弄ってみると以外にも伸びしろがあるという面白い内容でした。
何よりphpでも結構戦えるね～というのが解って嬉しかったです。
今回は失格という残念な結果に終わりましたが、
次回必ずや本選に行けるように日々精進したいと思います！



あ！大事な事、忘れてましたね。
失格になった１つの理由ですが、恐らくお気付きの方もいらっしゃると思います。
～17:50にあったパートですね。

・セッション、MySQLデータのオンメモリ化　です。

我々はベンチマークを実施する前提でプロセスを立ち上げるのは問題無い
という確認をしていたので、ベンチマークソフトのinitに仕組みを仕込みました。

簡単に言うと、ベンチのinitでrsyncをして/dev/shmに移すという作戦でした。
再起動テストも実施して、完璧と考える状態で提出しました。

しかしながら、レギュレーションには以下が記載されていました。
"ベンチマーク実行時にアプリケーションに書き込まれたデータは、再起動後にも取得できること。"

もうお気付きですね。

これだと、実施後の再起動でデータの整合性が取れないんです。
私たちが失格した"たった１つ"の理由。それは・・・


「レギュレーションをちゃんと理解していなかったこと。」


次回は先ず読み合わせからやります！
っていうか、俺、遠い目をしながら最初にレギュレーション読んでた！
だまっててごめん！っていうか、スルーしてて、ほんとごめんなさい！！！


俺等は技術で負けたんじゃない！国語で負けたんだ！


という名言を文系エンジニアが吐いたところでドラマをクローズしようかと。


ちゃんちゃん。

外れないワインを選ぶ3つのポイント

今日は家族が居ないのでワインを飲みながら検証していたら、
makeしている間のネットサーフィンしてたんですけど、美味しいワインの選び方ってページが結構あったんですね。
気持ちよくなってきたので、ちょっと趣旨を変えて外れないワインの選び方でも書こうと思います。

まず第一に、美味しいワインの選び方なんてないと思ってます。
不味いとか美味しいというのは趣味だし、その人が感じる想いですよね。
たとえば、今私が飲んでいるワインをみんな美味しいっていうかというと、
まず大半の人はもっと美味しいのがあると言うと思います。
じゃ、美味しいワインの選び方ってなんじゃい？っていう話になるんですが、
結論、ないんです。　ただ、自分が好きだと思う味ばかりを選んで、
ワインの外れを極力無くすことは出来ます。
私は味とか美味しさとか、全然解らないんですよ。もうセンスの欠片もないｗ
という訳で、「外れないワインの選び方」です。
実際、色んな方に教えて外れないと言われるので、これ、ほんとに外れないと思います。
しかも、この方法をとると1本500円のようなテーブルワインも全然OKです。

何で外れないワインを選べるようになったかというと、理由があります。
ワイン好きっていうと何かあれな感じしちゃうんで、私の場合はそういう類と違います。
普段飲むのは酒屋で選んで高くても1本1000円以内のものです。
昔、ソムリエ気取りで高いワインを飲んだ時期があったんですが、全然美味しいと感じず。
タバコ吸ってたから細かい味なんて解る筈ないというのもあるんですが、飲み方を知らなかった。
ただ、これは高いワインなんだ。すげーみたいな。そんな感じだったと思います。
今考えると、とてつもなくもったいない事してたんですが、私は飲み手として成熟してなかった。
高いワインは飲み手も選ぶって話です。

んで、当時のワイン売り場のソムリエさんがオーストラリアのワインを勧めてくれて。
そこで出会ったワインにとても衝撃を受けまして。
これは凄いって事で、それから特に南半球を買い漁って飲んでました。
でも、当たり外れが凄いあるんですよね。要するに好みじゃないワインが混じって来る。
常に美味しく飲みたい私は飲んだワインを記録とってみたんですね。

毎度前置きが長いんですが、ここからが本題です。
美味しいと思ったワインを記録から分析すると傾向がわかりました。

１．緯度が殆ど同じ。
２．葡萄の品種が殆ど同じ。

この2点です。
気候とか土壌とか、細かい味を作る要素なんか殆ど私には解りません。
単に美味しいワインの生産地だなって思う国を並べると、「オーストラリア・チリ・南アフリカ」なんですよ。
それぞれの国の北と南では相当緯度が違うんですが、美味しいと思うシャトーがある緯度が殆ど一緒なんですね。
あと、葡萄の品種。私の場合は前述の通り「シラーズ」という品種を美味しいと感じるという事がわかりました。
ちなみに私が好きなのは南半球のシラー種。例えばイタリアのシラーとオーストラリアのシラーズは品種が同じですが
抽出の製法が違うので、全く違う味になるらしいです。奥深いですね。

3つのポイントで2つしかあらへんやんけ！って感じだと思うんですが、もう1つは買った後です。
上記2点でも、あれ？外れた？って思うことがあるかもしれませんが、その時はおまじないをします。
一旦開けた後に、ビンをブンブン振ります。星付きシャトーの高いワインでは絶対にやらない事だと思いますが、
空気に触れさせることを強制的にさせるのは安いワインでは結構重要らしいです。
たとえば、コノスルというワインがあります。これはチリのワインなんですが、
オーストラリアのデ・ボルトリや南アフリカのオビクワとちょっと違ってスパイシーです。
開けて1日置いておくと丁度良くなります。1日待てない時は、ブンブン振ります。

たったこれだけです。これだけで自分が美味しいと思う外れないワインを選べます。
緯度まで解るかい！っていう人は、南半球であれば国名を覚えておけば大体OKです。

ITに話を戻しましょう・・・もともとしてないですが・・・

これは、身近なデータの活用でもあります。分析をして傾向を知るのは重要なことだと思います。
自身が購入したワインの蓄積データを活用して、1つの答えを導きだしています。
これが店舗単位になってくるとワインの売れ行きから、その地域のワインを購入する客層をターゲットとして、
品揃えを考えたり、新しい商品ラインナップを考えたり出来るわけですね。

統計的にオーストラリアのワインを買うお客様が南アフリカのワインを買う確率が高い。
というデータが導き出された時、オーストラリアのワインを買ってるお客さんに、
南アフリカのワインを勧めればとっても効果的ですね。また、逆もしかり。
こういうアプローチってネットではよく見ますね。

スーパーやコンビにでは、当たり前のようにビッグデータが活用されてますが、
まだまだ個人商店規模や小さいスーパーではデータの活用余地があるんじゃないかな。
と思ってます。個人向けのデバイスはどんどん発展してきているので、後は解析手法や
インタフェースが充実してくれば、より身近になっていくと思います。

ビッグデータの活用は廃棄率低下にも繋がり、究極のエコにも繋がると思います。
ビッグデータがより身近になって、地球がよりよくなっていければ良いと思いました。

外れないワインを選ぶ3つのポイントを地球規模の問題にして、この文章を閉めようと思います。

2014年に思う事

あけましておめでとうございます。
今年もよろしくお願い致します。

2014年になりました。
昨年を振り返ってみると、vagrantやらchefやらが成熟した感が半端なく、
またzabbixも2.2になって大分クラウド環境に馴染んできました。
APIもだんだん成熟してきており、世界に広まるのも時間の問題かなという感じになっています。
NagiosベースではsensuがAPI系で注目株となっています。自動化は加速していくばかりです。

クラウド業界では満を持してマイクロソフトのAzureが日本リージョンを発表しました。
日本リージョンは作らないって言ってたのにずるいなぁ・・・と思ったのは内緒です。
今年の上半期にリリース予定となっています。Azureを未だ触ってない方はお早めに。
お金持ちだからか、かなり大きい事例も増えてきており、目が離せない状態になっています。
マイクロソフトが復権する日も近い気がします。というより、既に来てます。
今年でAWS1択から2択になるぐらいに成長してくれるだろうと注目をしています。

さて、2014年は私はIT運用自動化元年になると考えています。
2010年がクラウド元年。CMでも佐藤浩市がクラウドの話をしていました。
たった4年で市場がここまで大きくなりました。
今やクラウド戦略が鍵を握るといっても過言ではありません。

その流れで自動化も加速していきました。
AWSの影響はとても大きいと思います。歴史を作る企業とはキャッチフレーズだけではありません。
AWSのお陰でインフラAPIでソフトウェア化が加速し、開発者も気軽にインフラを触れるようになりました。
DevOpsなんて言葉が2012年頃から流行り始めて、今では当たり前のキーワードになってます。

今年はその成熟したIT運用自動化がサービス化されていく年だと考えています。
オペレーションだけを行っているようなIT運用は今後、本格的に淘汰されていくでしょう。
いかにあらゆるリソースデータから解析を行いKPI化していけるか。プロアクティブに提案できるか。
それが運用者の仕事となっていくと思いますし、そうしていかなければいけないと信じています。
「アウトプットは障害対応です。」というIT運用の発想は今はまだしも、今後は通用しないでしょう。
要するに世の中の殆どのMSPが淘汰される。MSP自体の考え方が変わるという事です。

私は世の中のMSPは無くなったほうが良いと思ってます。
（MSPに属する人間がこんな事を言うと怒られてしまうかもですが・・・）
具体的には働き方や売り方を変えるといったほうが正しいかもしれません。
IT運用のスペシャリストであり、私のIT運用の師匠がこんな話を結構前にしてくれました。

「障害が発生して人が電話をするのっておかしくない？　だって、お客さんは絶対に怒ってるじゃん。
　怒ってるの解ってて電話するなんて、そんなの人じゃなくて機械がやれば良いんだよ。」

今までは24×365で有人で監視していることが優位だと思っていましたが、
この話を聞いた時、初めて私は「有人監視」の優位性が吹き飛びました。
とても単純な話です。「人が人らしく働くために、人がやらなくても良い事をを機械にやらせる。」
IT運用、特にMSPのユーザが求めてるのは人が電話してくることではなく、
「正確な情報が伝達され、かつ素早く対応が行われること」だと思います。
その後に人としてのコミュニケーション、やり取りが必要なケースはあると思いますが、
1次対応に人である事を求めている訳ではないとおもいます。

人が判断して切り分けを行い、そして本当の障害だけを通知するようにする。
というのが有人監視の優位性と言われるところだったと思います。
しかし人が判断する内容が「決められている事」であるならば、それは自動化可能です。
自動化出来る為の材料が成熟して出揃っている以上、やらない理由がありません。

今年の展開等は色々と考えたり、自社のメンバーとも話をしていますが、
プラスαを提供して、MSPらしさが出せるようなIT運用自動化を考えています。

今年はIT運用のスペシャリスト見習いとして、IT運用業界に貢献できるような動き、
既存のMSPの概念を破壊するような動きをしていきます。
（あくまで私はMSPの中の人です(笑)）
ちなみに、一緒に破壊してくれる人も募集中です（微笑）

どうか本年もよろしくお願い申し上げます。