インフラエンジニアからみた「IE依存」の現実

IE依存の話題

かの山本一郎氏が「IE依存」を取り上げてくれていたので、インフラエンジニアの観点から見た問題点を記載しておきたいと思います。

news.yahoo.co.jp

明らかにオンプレミスに残るIE依存問題

Webブラウザで、インフラ基盤をコントロールすることがどんな場面であるかということをまず整理します。

・スイッチ・ルーターなどの機器の管理画面がWeb化されているが、動作保証しているブラウザが限定されている。

・ロードバランサーの管理画面が・・以下同文。

・ファイアウォールの管理画面が・・以下同文。

・物理サーバーのリモート管理コントローラーが・・以下同文。

・仮想基盤（VMwareなど）の管理画面が・・以下同文。

ということで、この10年ほどのトレンドとして、インフラ基盤を構成する機器、特にアプライアンス機器の管理画面がWeb化するという状況にあります。

昔はGUIアクセスするためには、端末に専用のクライアントを入れねばならず、しかも機器のバージョンにクライアントのバージョンも合わせなければならず、運用管理が大変でした。Web化することによって、クライアント側はWebブラウザからアクセスできるのでバージョンの差異に関わらず端末からすぐ機器にアクセスできる、という夢のような話です。

ところが、です。

基本的にアプライアンス機器のWeb画面はInternet Explorerを前提としていました。昔はIEのシェアが一番だったし、Windowsには必ずIEがプリインストールされていましたので、各アプライアンスベンダーもIEでさえ動けば大丈夫・・という姿勢でした。

例として、ファイアウォール大手のJuniperの機器のブラウザ前提条件を見てみましょう。

Juniper Networks製品 FAQ(よくあるご質問)｜Juniper Networks製品サポートサイト

J-Web使用時にサポートされるブラウザを教えてください。
公開日 ： 2017/11/01
更新日 ： －
以下の通りです。

■Junos 12.1X44/12.1X46
　・Internet Explorer 7.0
　・Mozilla Firefox 3.0

■Junos 12.1X47/12.3X48/15.1X49-D40～D90
　・Internet Explorer 8, 9, 10
　・Mozilla Firefox 23以降
　・Google Chrome 28以降

■Junos 15.1X49-D100以降
　・Internet Explorer 10, 11
　・Mozilla Firefox 44以降
　・Google Chrome 55以降

よく状況を示した資料かと思うのですが、機器のファームウェアバージョンが古ければ、IE7とFirefox3しかサポートしないという有様です。ファームウェアを最新にする運用をしていればかろうじてChromeにも対応できるのですが、動いているシステムにて神経質にファームウェアをアップデートする現場はとても少ないと思います。

次に、物理サーバーのリモート管理の例です。DELLのサーバーにはiDRACというリモートからサーバーを管理できるモジュールが内蔵されています。

[iDRAC] 対応ブラウザ確認手順 | Dell 日本

本ドキュメントでは、iDRACのWebコンソールが対応しているブラウザを確認する手順について説明します。

サポートされていないブラウザでWebコンソールを起動しようとすると、ログインできない、ログインできても一部操作ができないなど不具合が発生する可能性があります。
対応ブラウザはファームウェアのバージョンによって異なるため、お使いのファームウェアバージョンのリリースノートを必ずご確認ください。

こちらも同様に、データセンターに入らずリモートから物理サーバーの状況を見たい、というときにiDRACへWebブラウザからアクセスするような運用保守の仕組みを確立しているシステムも多いと思います（HPEだとiLO、富士通だとiRMC、NECだとEXPRESSSCOPEエンジン、ベンダーによって違います）。

DELLに限らず、ファームウェアをバージョンアップすることにより最新のブラウザに対応していく暗黙の了解があるのですが、どれだけの物理サーバーがファームウェアバージョンアップをきっちりやっているのでしょうか。

現実は、納品してから大きな問題も起きない限り、ファームウェアのバージョンアップなどしないのではないでしょうか。

データセンター内の管理端末内ブラウザをバージョンアップしないようにして、安定運用するということをやっている現場がほとんどではないのかな？と思います。

このように、WebシステムにおけるIE依存問題ももちろんあるのですが、オンプレミスの複数の機器のWeb管理画面のIE依存問題というのも根深くあるというのが、インフラエンジニアから見た「IE依存」です。

ファームウェアを全機器最新にすれば、おそらくChromeやEdgeに切り替えてもよさそうですが、現場のインフラエンジニアからすると、めまいがしそうな作業になると思います。特にファームウェアをバージョンアップすると一部動かなくなったりする機械もありますからね・・。

対応していないバージョンでアクセスするとどうなるか

対応しないブラウザでアクセスしたときの機器の反応は様々です。そもそも、「ブラウザが対応していません」と、User-Agentでバッサリ切ってくる機器もたまにあります。まだそれは潔いのですが、困ったことに、動いているかのように見せかけて、実は不完全にしか動かないということがあります。

例えば、ファイアウォールのルールを確認しようとして、あるオブジェクトの「＋」マークをクリックしても、さっぱり情報が展開しない。動的なページではJava Scriptが多用されていますがブラウザ間の互換性のためにエラーとなってしまうようです。

Javaアプレットの問題もよく見かけました。Chromeでは早々にサポートを廃止しています。

JavaとGoogle Chromeブラウザ

OracleもIE使えと言ってるぐらいですので、古い機器の管理画面ではIE専用、というのも致し方ないと思います。

ということで、バージョンによっては動かなかったり、不完全に動いたりと、本番システムをドキドキして触っているインフラエンジニアとしては、不完全に動いてしまうことが最も怖いです。ということで、Webブラウザのバージョンを固定して、管理端末として使っている現場は非常に多いと思います。

どうなってほしいか

最後にファンタジーを。ブラウザは一種類で、もうセキュリティパッチ以外のバージョンアップなどしなければいい・・。

これはインフラエンジニアに限らず、全てのWebブラウザを使うエンジニアの願いなのかもしれません。

・・・とは行きませんよね。ファームウェアをちゃんと上げなさいというベンダーからの合唱が聞こえます。

だから、クラウドは楽だなあ・・と、思います。

インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27

Google Chrome 68がリリース。証明書のないサイトがどんどん強調されていく。

保護されていない、が表示されるように

Chrome 68がリリースされたということで、私のChromeも更新してみました。

そうしたところ、確かにHTTP（平文）のサイトは見事に「保護されていない」ということになりました。事前の報道通りですね。

はてなブックマークも、この有様です。

「保護されていません」というエリアをクリックすると、

と言う具合に、結構おっかないことが書いてあります。

これで終わりではない

Googleの計画は下記サイトにまとめられています。

www.chromium.org

このうち、「July 2018 (Phase 3)」までが完結したということになります。

今後の予定ですが、今年9月のChrome 69で、「保護された通信」という記載がなくなり、グリーンがグレーになります。

未定ですが最終的には、アイコンすらなくしたいとGoogleは言っています。暗号化しているのは当たり前としたいということになると思います。

EV証明書の場合だけ企業名を出して緑のままにするんだと思います（多分）。

今年10月のChrome 70においては、保護されていない通信つまりHTTPのサイトで、何かフォームに文字を入れようものなら、色が変わる仕掛けを用意するようです。

最終的には予定は示されていませんが、HTTPサイトはもっと危険性を目立たせたいとのことです。

モバイルだとこんな感じ・・。

今後の見通し

IEやEdge、FirefoxやSafariなど、他のブラウザが追随するかどうかがポイントだと思います。Chromeだけ、HTTPS通信に何のマークも出さなくなると不安になりますよね。

2018年は明らかに過渡期で、特にユーザー向け手順書を作っているエンジニアの人は、仕様がどんどん変わって仕事が増えているかもしれませんね。

追記

経産省や総務省が共同通信からDisられてますね。

this.kiji.is

あら大変。

Web担当者のためのセキュリティの教科書

障害報告書を書くときに気を付けるポイント

はじめに

最近は、システム障害ウォッチャーとしていろんな種類の障害報告書を読んでいます。個人的に様々気が付くことがあるのですが、ある基準をもってコメントを入れています。これをまとめておきたいと思います。

ポイント

以下、ポイントが5つあります。

1. 現象と影響

まずは客観的に、ユーザー目線でどういう不具合が起こったかをわかりやすく記載することが大切です。技術者目線で書き始めるとこの時点で読み手から「意味がわからない」と言われてしまいます。システムを使うのは技術者ではないことが多いので、あくまでも平易な言葉で現象を明確に記載しましょう。また、この時点で経緯は不要です。結論から先に話す、という意図を持って現象を記載します。

また、この現象が発生したことによるユーザー側への影響も、現象の次に記載すべきです。そのシステムが使えなかったこと（現象）により、何がユーザーに不利益が起きたのか（影響）ということです。例えば、ストレージの過負荷が現象とすれば、影響は仮想OSが応答不能になりロードアベレージが上昇しサービスできなくなる、といった具合です。

このように、現象と影響は表裏一体であり、影響がゼロである場合はおそらく報告書すら出さないと思います。影響の大きさにより障害のレベルが変わっていきます。

2. 経緯

ユーザーは厳しいので、障害は分かったが本当に運用／障害対応は適切に行われていたのか？という目線で見てきます。特に問題が長期化するとユーザーのストレスはこの一点に集中します。問題を切り分けたり解決したりする技術力がないのではないか。誤った判断で二次被害を引き起こしているのではないか。運用体制に欠陥があり対応できる技術者がすぐにアクションできなくなっていないか。技術者ばかりでこれらを統括する経営側が把握できていないのではないか。などです。

経緯を細やかに表現することにより、運用や経営、つまり中の人が適切にアクションを行っていたことを表現する必要があります。ここで個人名を出す必要はありません。法人としてのプロセス運用・プロセス管理が問われているのです。

経緯を適切に情報公開することにより、かえってユーザーからの信頼を勝ち取るケースもあります。大切な情報の一つです。

3. 原因の考察

原因を考えるときに２つの目線が必要です。

・なぜその不具合は障害前に予見できなかったのか（作り込み）
・作り込まれてしまった不具合が、なぜ今のタイミングで発現したのか（流出）

案外、流出の理由しか述べてない報告書が散見されます。例えば、オペレーターが環境を誤ってコマンドを投入したから、と言って終わりにする報告書はよくあります。この時点でヒューマンエラーだけを原因としてしまうと、後段の再発防止策は、手順書作成の徹底、レビューの徹底、本番運用ルールの教育徹底、といわゆる徹底の濫用が発生します。

問題は、なぜ環境を誤ったか。ホスト名が本番と開発で同じであり間違いやすかったのかもしれません。運用部門が手薄で大変な量のメンテナンスを一人で行わなければならず、間違いは単に確率の問題だったのかもしれません。エラー率は一定なので、作業をやればやるほど誤る可能性は高くなります。障害の前日、社内の飲み会が遅くまであり翌日の注意力が落ちていたのかもしれません。

運用体制の不備、であればもはや障害前からの問題であり、環境を誤ってコマンドを投入したことは流出要因なのですが、もともといろいろな理由で引き起こす条件が整っていたのかもしれません。

このように、起こったことだけに注目せず、なぜ起こってしまったのかは深掘りする必要があります。特に経営者目線であれば、運用体制や作業環境、人間関係や指揮系統など広い目線で検討する必要があります。技術者に報告書を書かせると、確実にこの視点が抜けてきますし、報告書に前日飲み会だったからとは書けないですよね。

対外向けにどれだけ、本当の考察結果を晒すかはともかく、社内的には一番大切な活動だと思います。ここで、流出させたエンジニアだけを責めて終わりにする企業は二流三流だと思います。

4. 暫定対応

再発防止策に入る前に、まずは影響を最小限に抑えるために、どんな暫定対応を取ったかまとめる必要があります。これ以上影響が広がらないことをユーザーに伝えて安心感を得ることが目的です。

5. 再発防止策

大した原因の考察も無しにいきなり再発防止策に入る報告書は、内容が薄いことが多いです。その場合、基本的に「徹底」が増えます。これは流出要因たるエンジニアに、経営がプラスアルファの負担を要求する図になりがちです。

正直言って、障害を起こしたいエンジニアは一人もいません。でも起きるのです。起きないようにするためには運用体制の充実や、ミスしても影響が最小限に済むような構成にするための投資が重要です。

例えば経営的には、どんどんアプリケーションのリリースをして売上を伸ばしていきたいと考えているとします。しかしリリース作業などの変更の前提として、インフラが耐えられるかという側面からのキャパシティープランニングや、ステージング環境の準備試験、変更作業に伴う手順書の準備やレビューなど、いろいろな作業が発生します。作業がどんどん増えると、確率の問題としてヒューマンエラーが発生します。どんなに作業をしても失敗しないようにしなさい、というコマンドで疲弊するインフラエンジニアが多いのも事実です。

Kubernetesなどのコンテナ技術や、サーバーレスといったアーキテクチャーはこのあたりの問題を解決するために今盛んにアップデートされています。私個人はまだ中立的なのですが、アプリケーションのリリースが激しいWEBサービスの分野では一理あると思っています。変更が緩やかなシステムだと、これまでの3層（WEB/AP/DB）の方が相変わらず安定すると思っています。

このように、再発防止策を現場の技術者だけに押し付けることなく、経営資源の最適化と言った部分でマネジメントと技術者が一体感を持って再発防止策につなげられる会社が強いと思います。

エンジニア目線では作業すればするほど、障害に当たる可能性は高くなりますので、たまたま引いてしまったときに責任追及されるというのは、バカげているというのが私の意見です。作業を避けまくるエンジニアが得してしまうことになりかねません。

最後に

障害発生中においては、障害報告書を書くべき人が障害対応を行っていたり、リモート対応しているために何が起こっているか情報が社内で錯そうしたりと、難しい状況に追い込まれます。この中でポイントを抑えた報告書を出せる企業は、結果として顧客から信頼を得ます。

そして、障害報告書から学びそれを経営や現場に活かせていく企業が、最終的にITの世界では生き残っていくと思います。

新人ガール ITIL使って業務プロセス改善します!

5GとSSDが次世代ITインフラの本命となる

インフラエンジニアを悩ませてきたボトルネック

現在のITインフラ、クラウドもオンプレミスもひっくるめて、一番のボトルネックはどこにあると思いますか？。

1つはインターネットの速度。もう1つはストレージです。

インターネットの速度が遅いと何が起こるか。WEBサーバーのセッションを長い時間占有してしまいます。端末があって、画像やテキストなどのコンテンツをダウンロードするのですが、もちろんダウンロードし終わるまでは１セッションを確立していなければいけません。瞬時にダウンロードしてくれれば１つのサーバーからたくさん配信できるのですが、特にモバイル中心の現在だとこの遅さを許容する設計にしなければいけません。現在は、CDNというサービスを利用することで、CDNネットワークの末端にたくさんのコンテンツサーバーを配置して配っている状況です。ただしCDNは動的なページを表示させることはできないので、根本的な解決にはなっておらず設計を難しくしているポイントとなっています。具体的には動的なページはキャッシュせずにアプリケーションサーバーに問い合わせに行かせるなどの設計を行います。

もう１つ。ストレージの遅さです。ハードディスクは遅いとよく言われますが、昔と比べて遅くなったわけではなく、読み書きのスピードに限界が来てしまったのに、１基のハードディスクの容量が巨大化してしまったということが起因しています。SATAのハードディスクが今や12TBまで来ました。12TBもあったら全部保管できる～、というのは呑気な話で、障害が起きたら消失する単位が12TBになったということでもあります。しかも、この12TBをコピーして違うデバイスにコピーするスピードが絶望的に遅い。特にハードディスクの特性上、ランダムアクセスに非常に弱いので、システムとしてこのような大容量ディスクを使うのはバックアップの保管の用途だけという頭で使っています。ただ、このバックアップ用の大容量ディスクに複数のシステムから書き込みを行うとそれだけでかなりのボトルネックになってしまうので、できるだけ使いたくないデバイスに成り下がっています。1TB x 13 x RAID5、などとすると少しは早いのですが、そうするとディスクの本数が増えて、ディスク破損の確率も増え、数年すると毎月のようにどこかのディスクが壊れるということになります。

5GとSSDが次世代ITインフラの本命となる

最近の5GとSSDのニュースは、上記のボトルネックを美しく解消すること間違いなしです。

japan.cnet.com

次世代のセルラー技術である5Gは、無線ネットワークの速度、通信距離、応答性を大幅に向上させると期待されている。今日の標準的なセルラー接続の10〜100倍の速度が達成可能で、家庭に敷設された物理的な光ファイバケーブルを使用するどのような手段と比べても、それ以上の速度向上が期待できる。テレビ番組の1シーズン全体が数秒でダウンロード可能で、医師によるリアルタイムの遠隔手術も可能になる見込みだ。

 5Gによって家庭の光回線まで無くなってしまうのかどうかはともかく、可能性としては端末の持つネットワークのボトルネックは解消されることになります。そのためWEBサーバー側は後述の次世代SSDのようなストレージと、太いインターネット回線があれば大量の端末にコンテンツを大量配信できるようになります。これまではロードバランサーと複数台のWEBサーバーの組み合わせが鉄板でしたが、台数自体は少なくてもカバーできるようになると思います（むしろAZを分割することの方が重要）。

pc.watch.impress.co.jp

2.5インチサイズのSAS SSDでは、世界最大容量となる32TBモデルの出荷も開始するという。この32TB SAS SSDを利用すれば、HDDを利用する2ラックサイズのストレージサーバーと同容量を、2U×2のサイズで実現可能になるとともに、読み出し速度も第4世代V-NANDの採用によって従来よりも2.5倍高速になるという。

ドライブ1基が大容量化するとともにその読み書きスピードがそれに合わせて高速化していくことが、ハードディスクの終焉・SSDの進化で現実になりそうです。そうすると何が起きるか。無理に小容量の複数ドライブでRAIDを組まなくてもよくなります。32TBのSSD1本と別の2本にレプリケーションしておくなどハードディスクでは考えられないような運用ができます。ハードディスク時代のRAIDは、いろいろと問題を起こしていたことはインフラエンジニアの業界では有名です。RAIDを組んでいたのに3本同時に壊れたとか、RAIDの再構築が数十時間終わらないとか、再構築中にもう一本壊れたとか・・・。大容量高速SSDの登場でストレージのアーキテクチャーがもっとシンプルになると思います。大容量が欲しいのではなく、ほぼ壊れないストレージが登場することになりそうです。

特に、ハードディスクは、読み書き時にはヘッドを動かしアクセスするので、振動が生まれるのですが、その振動に弱いというジレンマを抱えています。近年は扱うデータが巨大化しているのでディスクの本数も物理的に増え、保守されている方は毎日のようにオレンジランプのお世話をしているのではないかと思います。SSDでは電気信号の交換だけで済みますので振動に強いと言われています。保守もずいぶん楽になることになります。

バックアップの考え方が大きく変わる

大きなデータを瞬時に、SSDから読み出し、5Gで、別拠点のSSDに送る。

この設計ができるようになると災害対策が相当に楽になります。今のTB級のデータを他の拠点に送るのはかなりの無理ゲーです。重複排除などの技術もあり、細い帯域で素早く送る研究もされていますが、そもそもストレージの読み書きが遅いのです。道も細ければ車も遅い。重要データだけ転送するので精一杯なシステムも多いと思います。

次世代インフラの場合は、道が太くなり車が激速になり、しかも車の台数も増えるイメージです。

アフター次世代インフラ

5GやSSDのほかにも、CPUの多コア化や、パーシステントメモリーの話もあり、5年くらいの間に大きな変革が起こるのではないかとにらんでいます。

cloud.watch.impress.co.jp

pc.watch.impress.co.jp

全部組み合わせたときにできるその姿は、数Uでクラウドの能力を凌駕すると思われ、再度「クラウド？オンプレ？」の議論が復活するでしょう。HCIのように仮想化技術をプリインストールしプライベートクラウドを提供するスタイルが、もっと物理的にサイズが小さくなり、かつ性能が飛躍的に向上することによりぐっと魅力的になることも容易に考えられます。

私も今はクラウドに避難していますが、「壊れないオンプレ」「2Uですべて賄えるサーバー」が出てきたらまたオンプレに戻りたくなってしまいますね。次々出てくる新技術に注目しています。

すべてわかる 5G大全2017

スタディストの障害報告書にいろいろと思うこと

スタディスト事件？

日経xTechの記事で、スタディスト事件なるものが発生し本日最終報告書が公開されていたことを知りました。

tech.nikkeibp.co.jp

マニュアル作成・共有サービス「Teachme Biz」を手掛けるスタディストは2018年7月23日、6月26日に公表した同サービスへの不正アクセスは、従業員の作業ミスによるものだったと発表した。可能性があるとしていた顧客データの流出もなかったという。

最終報告書はこちらです。

不正アクセスによる一部データ流出の可能性に関する詳細調査のご報告（最終報） - 株式会社スタディスト

何も無かったので良かったですね、と言うのは間違いないのですが報告書を読むと一介のインフラエンジニアとして思うことがありますのでまとめておきます。

思うこと

1. ISMSの取り扱いがよくわからない

まずは、以下の対策が気になりました。

・セキュリティ管理体制の整備
ISMSに準拠した形でのセキュリティ委員会およびワーキンググループを設置。社内外のセキュリティリスクに対する活動推進を総合的に管理、監督。

スタディストって、ISO27001の認証をすでに受けていますよね。

セキュリティポリシー - 株式会社スタディスト

ISO27001においては、セキュリティー委員会の常設は取得条件なのですが、これが機能していなかった、ということなのでしょうか。

しかも、上記のページ、よく見ると・・。

有効期限日が切れていますよね・・。認証自体は更新していて、ホームページの更新忘れなのでしょうか。他の会社を見てみましたが、有効期限が切れている会社はなかったです。

ともかく、ISMSに準拠した形でのセキュリティ委員会の設立が対策になっているにもかかわらず、一方でISMS取得済みというのがチグハグなのが否めません。

とりあえず、ISMS取得済みということで話を進めます。

2. リスクアセスメント、そしてその対応ができていないのではないか

今回、インフラエンジニアが誤って本番に接続してしまったことが、問題のトリガーになっています。

・本番環境へのアクセス経路を厳密化
業務用端末と運用端末の分離を実施。社内外からの意図しない接続を防ぐため、本番環境への接続はVPN経由のみに制限するなど、本番環境へのアクセス経路や権限を厳密化。

ISMSを取得しているのであれば、リスクアセスメント時に、本番と開発のネットワークが同居しているリスクを列挙できているはずです。これはなぜ許容されてしまったのでしょうか。許容されていなかったとすれば、なぜ対策されていなかったのでしょうか。この点についてマネジメントレビューを受けていたでしょうから、最終的には最高セキュリティー責任者（普通は社長）の責任であると思います。

今回問題が起こったから塞ぐというふうに読めるのですが、そもそもISMSの目的は事前にリスクを洗い出し、優先度・緊急度の高いものから対応していくということが主旨のはずです。

ISMSの取得が目的となってしまい、実際のPDCAが回っていない、ということはどこでもよくある話ですがその状況と同じではないのかなと思いました。

問題への対処は大事ですが、最も大事なことはISMSの根幹であるリスクアセスメント、優先リスクへの対処、またきちんとそれがなされているかのチェックと改善、といういわゆるPDCAを、スタディスト社でどう回すかが不明なのが、私の違和感の根本になると考えています。

なぜ、開発と本番の同居をISMS取得時に見逃してしまったのかを知りたいです。

インフラエンジニアはそのリスクが排除されていないことでたまたま失敗してしまっただけであり、リスクの作りこみはもっと前（環境構築時）から始まっていたのではないかと考えます。

3. 障害報告書に徹底、厳密、強化と言う言葉は使うべきではない

徹底、厳密、強化と言う言葉が何か所も見受けられます。私が障害報告書をレビューするなら、この表現は極力避けます。

・本番環境へのアクセス経路を厳密化

・運用ルールの強化および徹底

・重要作業のマニュアルにおける管理の徹底

・ログデータのより詳細な取得と管理、解析力の強化

・従業員教育の徹底

これらの言葉は行動を表す言葉ではありません。「がんばる」という言葉のニュアンスと似ているのですが、程度の問題であり行動を客観的に表している言葉ではありません。

例えば、

「品質管理部を新設する。この部署にて、開発部署の作業ログを監査し適正であることを担保する。かつ、外部監査時に品質管理部が適正に監査していることは毎回確認する重点ポイントとする。」

という書き方をすれば、徹底していることが行動として表現できます。徹底というのは今年の徹底と、3年後の徹底が同じである保証がなく定量的な表現ではないということです。

よくお客様サイドで言うのは、「徹底できなかったから問題になってるんだから、対策が徹底というのはおかしいだろう」という指摘です。確かに私もそう思います。

自社の報告書で、再発防止策に「徹底」もしくはそれに似た言葉が出てきたら注意しましょう。たいてい対策になっていないので、再発するでしょうし、かつ、次の報告書にも「徹底」と言う言葉が出てきたら末期状態（PDCAが回らない）です。

4. 役員の怒りが見える

そもそも本件、第一報については「不正アクセスの可能性」ということで社会に報告しています。第三者にて調査を進めたら結局は「社内の開発部のオペレーションミス」となってしまいました。初動の段階で、社内のみと気が付いていたら第一報の表現も変わっていたはずです。社内のインフラエンジニアが初動の段階できちんとログ解析ができていれば良かったのに、しかも原因がインフラエンジニア。インフラエンジニアめ！。そんな怒りが透けて見えます・・。

・ログデータのより詳細な取得と管理、解析力の強化
社内ネットワークログの保存を徹底。ネットワークトラフィックの監視も強化し、管理を徹底。保存したログに対して適切な解析が行われる体制を整備。

徹底が2回も書いてありますものね。

まあ、もし社外からの不正アクセスだったとしても、解析にこれだけ時間がかかったことでしょうから、今回を機に整備するのはとても正しいと思います。

整備が何を示すかはわからないのですが、きちんとお金をかけてソフトウェアやアプライアンスを購入し設置すべきと思います。お金をかけられるなら、ここにも外部ベンダーを入れ、役員レベルで動作を検収すべきでしょう。このあたりに、お金をかけない判断をする経営者は意外に多いものです。何もなければ1円にもないのでコストを抑えがちです。しかし、一旦問題が起こると、ちゃんと整備しとけばよかった・・となります。セキュリティー投資の「あるある」だと思います。

5. 従業員へのセキュリティ教育の徹底・・・それってISMS

2番と同じツッコミです。

・従業員教育の徹底

　今後は二度とこのような事態が発生しないよう、これらの遵守を徹底するとともに、さらなるセキュリティ対策強化に取り組んでまいります。

従業員へのセキュリティ教育はISMSの基本ですね。

6. ちょっとした皮肉

サービス自身がマニュアル作成・共有サービスなのに、

・重要作業のマニュアルにおける管理の徹底
アプリインストールやアカウント設定等の重要な作業のマニュアルは、公開時のレビューを徹底。公開後も半期に一度見直しを実施。

マニュアルのレビューが徹底されていないという皮肉。Teachme Bizの機能一覧を見ていますが、レビュー機能がないなあ・・。

Teachme Bizの機能｜マニュアル作成ツール Teachme Biz

補記

ちなみに、第一報の素早い公開や、第三者機関にすぐ調査を依頼したことそのものは、対応としては正しいと思います。その結果やプロセスが役員から見てあまりにもひどくて、このような荒々しい最終報告書となったのではと推察します。

ただ、ISMSを正しく運用できていなかったのは、役員の責任です。問題が起きて初めてPDCAが回っていなかったことが露呈したのだと思いますが、もし普通にISMSを運用していたら、「開発と本番のネットワークが一緒で危険」という項目が上がってこないはずはないです。もし役員レベルでそこに気が付けないとしたら、役員にセキュリティーの知識を持つ人（CSO）を選定すべきです。

なぜなぜ分析、という有名な障害解析方法によれば、障害の原因は2つに分割できます。

・作りこみ要因・・・障害となる動作を設計・構築時に作りこむこと。本来はシステムテスト・運用テストにて検出されるべきなのが、なぜかすり抜けて本番フェーズに入ってしまった。
・流出要因・・・作りこまれた要因が、何らかのトリガーにより露出してしまった要因。

結局のところ、インフラエンジニアのミスは流出要因でしかありません。なぜ本番と開発ネットワークの同居を本番リリース時に見逃してしまったのか。また、それがなぜ放置され続けて来たのか。

中途入社でインフラエンジニアとしてアサインされたら、なぜか本番と開発が同じネットワークだった。先輩に聞いたが「そういうものだ」と一蹴された。みたいなことはこれもまた「あるある」だと思います。

本来はISMSで、そういったリスクを抽出し、能動的に対処するべきなのですが、ISMS取得が目的だとすると、あえてそのようなリスクに目をつぶったり、運用で対処するなどの名のもとに許容してしまったりします。

かわいそうなのはインフラエンジニア・・ということにもなりかねません。作りこみ要因についてはコストや無知、などの問題も絡むのですが、結局のところこちらの対策が将来のセキュリティー強化そのものになります。

ということで、なかなかのスタディスト社の報告書だったので、長文となりましたが、参考となれば幸いです。もちろん、個人（インフラエンジニア）の見解となります。

情報処理教科書 情報処理安全確保支援士 2018年版

2017年の国内インフラ市場統計が指し示す現在の状況

2017年の国内企業ITインフラ市場の統計

2017年の国内企業ITインフラ市場の統計（IDC Japanの調査結果）が公開されています

2017年 国内エンタープライズインフラ市場 ベンダーシェアを発表

商談等、顧客との会話の際、市場動向を会話することがよくありますが、その基礎情報として上記の記事はよく読み込んでおく必要があろうと思います。

前提条件

この調査は、企業向けのサーバーおよびストレージを合算したものとあります。ネットワーク機器は含まれていません。ネットワーク機器のシェアは以下に公開されています。またここでいうネットワーク機器は「 企業向けおよび通信事業者向けのルーター、企業向け無線LAN機器、コンシューマー向けを含むすべてのイーサネットスイッチの合計」とありますので、ここに含まれないアプライアンス機器（ファイアウォールやロードバランサー）は、上記の「国内エンタープライズインフラ市場」に含まれるものと思います。

国内ネットワーク機器市場シェアを発表

考察

いくつか、私の気が付いたことをまとめておきたいと思います。

1. クラウドが伸長しているにもかかわらず、プラス成長していること

妙な話で、クラウド化が進めば進むほど、サーバー機器は売れなくなるという伝説が固く信じられていました。しかしふたを開けてみると市場は小さくなっていません。AWSやAzureがあれほど成長しているにも関わらずです。

これは、企業におけるITの主戦場は未だオンプレミス側にあるということを指し示していると思います。むしろ、クラウドはアドオンであり、オンプレミスとクラウドを組み合わせて最適化していくことのほうが「普通」であることを指し示していると思われます。クラウドにはクラウドに適切な利用用途、例えばビッグデータ解析や突発的なトラフィックの処理、IoTの情報収集やAIの活用、サーバーレスなどがあり、オンプレミスの延長線上でうまく使っていくことを、各社で考えている状況であると思います。

一部のクラウドベンダーが言っているような、全てをクラウドが飲み込んでいくようなアピールを真に受けると、トレンドとはずれてしまうことを知る必要があります。適材適所が今のところ最善策と言えると思います。

2. メインフレーム強し

x86サーバーを2013年に早々と中国レノボ社に売却してしまったIBMのシェアが、8.6%もあり、しかもシェアは伸長していることについて意外な方がたくさんいらっしゃるのではないでしょうか。IBMは2017年にはz14という新製品のメインフレームを出荷していますし、以前はAIXやAS/400から発展したPower Systems、ストレージなどの製品もまだまだ取り揃えています。

エンタープライズ分野に目を向けると、メインフレームはオープン系に押されて斜陽のアーキテクチャーのように見られがちですが、現場は全くそんな状況ではないということです。かつ、過去のメインフレームのイメージとは全く違い、Linuxが動きますし、Javaやapache、コンテナやKubernetesまで動きます。下手にオープン系に手を出すより、メインフレームの方がハードウェアとしては堅牢というのは事実です（だが高い）。

一方で、下記のニュースのように、メインフレームを持たないNTTデータがオープン化虎視眈々と狙っていたりします。

NTTデータ、金融勘定系パッケージをメインフレームだけでなくオープン基盤でも提供 | IT Leaders

Microsoftやユニシスもメインフレームの切り崩しを行っていて、地方銀行勘定系のAzure化の話は話題になりました。

ASCII.jp：「勘定系をパブリッククラウドで」は地銀の声、BankVision on Azure計画の始り

大きな目で見ると、メインフレームの今の市場はなかなか手堅いなという印象です。

3. なんだかんだで富士通が強いこと

官公庁は国内ベンダー志向が強く、富士通とNECが寡占していることは知っていましたが、その中でも富士通は強いなと。これはSI部門がハードウェア含めて一括して案件が取れているということを示していると思います。かつ、公共だけではなく民間もカバーしているのがNECとの差ではないかなと思います。今までのSIの文化が今後も継続していくかはわかりませんが、現状日本でビジネスすると官公庁ではなくても、富士通の名前が出てきます。たしかにシェアが４分の１もあるとそうなるようなあという感想です。一方でNECは公共に閉じて強い印象があります。

4. ODM Directという不気味さ

数年前からうわさにはなってきたのですが、ODM Directのシェアが増加してきていきます。ODM Directとは何？という記事については、下記をご一読ください。

既存メーカーを中抜きする“ODMダイレクト”市場に成長の可能性：IDC調査 - ZDNet Japan

ユーザー企業ごとにカスタマイズしたサーバを開発、製造する メーカー（Original Design Manufacturer：ODM）を直接ユーザー企業に出荷する “ODMダイレクト”市場

具体的な例として、KDDIがODMメーカーからサーバーを購入している記事があります。

KDDI Cloud Blog ｜ だれも教えてくれないODMサーバの導入ノウハウ

サーバーベンダーからしてみれば面白くはないビジネスですが、クラウドも結局は提供側から見ればオンプレミスですので、ODMのシェアがじわじわ増えているのはこのためであろうとも思います。

市場の変化はこのODM Directのシェアを見ていればわかると思います。10%を超えてくると益々勢いが出てくるものと思います。ここは今後注目です。

結局のところODM Directが大きくなると、やっていることはDELLのサーバー部門と変わらなくなるような気もしますが。

5. HPEとDELLの争いは面白い

企業向けサーバーの選択時に、HPにするかなDELLにするかなっていうのはここ数年良くある出来事でした（少なくとも私の場合）。SIerが好んでHPEをカバーしているというのは何となくよくわかります。HPEの強みは何といってもパートナーのエコシステムがしっかりしているという点です。HPEが直接お客様をフォローしなくても、地場のSIerがフォローしてくれるということです。DELLはパートナービジネスに切り替えたのはまだ最近です。

【大河原克行のクローズアップ！エンタープライズ】デルのパートナービジネスは今度こそ本気なのか？ 8月に就任した松本光吉副社長インタビュー - クラウド Watch

DELLという会社はここ数年、VMwareやEMCの買収をはじめとしてM&Aでかなり人事面も含めて大変動してきましたので、SIerとしては困る面がありました。日本のサードパーティーは中小企業も多く、担当者はあまり変わりませんので、パートナーのエコシステムを持つHPEが強いのもわかるなあという感想です。対面でのつきあいを大切にする日本では、DELLよりHPEがSIerにウケるのもわかります。

今後はDELLもパートナーシップを強化していく・・というより、しています。

パートナーと共に驚異的な成長をこれからも──Dell EMC Business Partner Forum 2018 Tokyo：好調でも満足せず、パートナーと共にさらなる高みを目指す - ＠IT

端から見ていると、数字は嘘を付かないなあという印象です。

補足

こういうニュースを見ると、メインフレームを個人的に欲しいなあと思うのですが、この記事を思い出しますね（笑）。

大学生にしてIBM製メインフレームを自宅に設置＆IBMにスカウトされた「メインフレームキッド」のニッチな生き方とは？ - GIGAZINE

宝くじの一等賞金くらいないと買えないですしね・・。関われるエンジニアがうらやましいです。

進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus)

はてなブックマーク、人力検索はてな、はてなアンテナにアクセスしづらい障害（復旧）

はてなで障害発生

2018年7月20日 6:02ごろから、はてなブックマーク、人力検索はてな、はてなアンテナのすべてのページにつながりにくくなる障害が発生しています。 

7/20 はてなブックマーク、人力検索はてな、はてなアンテナにアクセスしづらい障害が発生しています - 障害・メンテナンス情報 - はてな

ネットワーク障害とのことで現在も継続中です。

なお、はてなブログは別のインフラのようで、当ブログは一安心です。

追記

2018/7/20 7:20AM

わかったことがあり次第、追記してまいります。

2018/7/20 7:22AM

はてなブックマークにアクセスしてしばらくすると、

と出るので、入口がnginxになっていて、これがロードバランサーになっているのではないかと推察します。急激なネットワーク負荷が来ている場合このような現象となることを体験したことがあります。可能性の一つとして、DDoS攻撃もあると思います。今後の情報を待ちます。

2018/7/20 7:44AM

公式アナウンスはありませんが、復旧しているように見えます。

2018/7/20 7:54AM

公式アナウンスがありました。7:30に復旧とのこと。

** 追記
2018年7月20日（金）7:30 ごろ、復旧いたしました。
ご迷惑をおかけして、大変申し訳ございませんでした。再発防止に努めてまいります。

再発防止、という言葉があるのでDDoSによるものではなく、何らかの設定ミスによるもののように受け取れます。

なお、はてなブックマークそのものは、さくらインターネットの基盤を使っているようですね。

さくら × tenki.jp × はてな、巨大システムを支えるインフラを語るイベント開催！ さくらのクラウド/専用サーバの裏側も話します@大阪 - はてなニュース

ASCII.jp：クラウド時代になぜ物理？メルカリ、はてながさくらの専用サーバを語る

はてなブログはAWSを利用しているようですが、はてなブックマークの方はIPアドレスから見てさくらにあるようです。

原因が気になるところですが、まずは復旧。

ネットワークはなぜつながるのか　第２版

感想文：「インフラ経験0の新卒エンジニアがインフラエンジニアになるまで」

「インフラ経験0の新卒エンジニアがインフラエンジニアになるまで」を読みました

はてなブックマークにインフラエンジニア関連の記事が上がっていたので、感想を書いてみたいと思います。

tech.leverages.jp

感想

インフラエンジニアのレイヤーが曖昧になっている

全体としてまず感じることは、インフラエンジニアという言葉のレイヤー（階層）がとても曖昧になってしまったことです。

レイヤー、ということでその階層をまとめます。

・ミドルウェア
・OS付属のライブラリ（OS標準のリポジトリで管理できるレベルのもの）
・OSそのもの
・仮想マシンの管理
・ロードバランサー
・ファイアウォール
・ストレージ
・ネットワーク設計（IPv4, IPv6）
・サーバーラック
・ケーブリング（LANケーブル・電源ケーブル）
・回線（インターネット回線、専用線等）
・データセンター
・バックアップ、監視、定期バッチ実行等の運用管理

アプリケーションのみ携わっている方は、上記のレイヤーをあまり意識しないかと思います。最近はクラウドを利用している場合は、物理的なものは抽象化され、クラウドベンダー側で管理してくれるようになりました。一方、オンプレミスのシステムをまだ運用しているのであれば、上記のレイヤーは相変わらず存在します。

昔は、インフラエンジニアと言えばサーバーとネットワークに分かれる、というのは度々書いていますが、クラウドが出てきたことにより、両方を一人のエンジニアが担当することも普通になってきました。ネットワーク設計は、クラウドだとGUIで設定した通りに論理的に動くので、CISCOだJUNIPERだYAMAHAだ・・といったベンダー間のお作法を吸収する必要もなくなりました。サーバーも段ボールから開梱して部品を組み立てて・・・データセンターに運んでケーブルを・・みたいな作業からも解放されました。

結果として、インフラエンジニア＝クラウドエンジニアという傾向がこの文章から見ても強くなっているのではないかな？と思いました。悪い意味で言えば、どんな分野でも少人数で対応しなければいけなくなり、若い人が短時間で把握するのは難しくなっているという感覚です。

少人数の体制は危険、でも・・。

おそらくこの記事の会社でも、「隣に座られていた先輩エンジニアが、1人でリニューアルのインフラ基盤の構築」を今後も手掛けるのはマズイと言う感覚があり、著者が冗長化の意味でアサインされたのではないかと思います。

経験的な話なのですが、せっかく体制に余裕ができたと思ったら、急に退職する話になります。もう何度も何度もあります。絶対に冗長化したほうがいいんですが、せっかくできたと思ったら辞める話になる。

これはなんなんでしょうね。きっと、自分が辞めてもすでに誰かと共有しているので大丈夫、という心理が働くんですかね？。たまたまマネジメント側にいるとたまったものではないです・・。属人化ダメ。けど、解消すると人が辞めるんじゃ元も子もない。

この仕事、オレじゃないと誰もできない、そんな感覚ってもしかするとインフラエンジニアには必須のエキスなのかもしれないです（ある意味迷惑ですが（笑））。

おそらく、サブの人は、今のままだとメインの人がいて出世できないから、手ごたえができた時点で他社で勝負してみようと思うんだろうなあ・・。

インフラ＝クラウド、というのは実はそうとう新しい

下記の表現は、私の考えるインフラとは、全く別の定義なんだなあという感想です。

インフラに興味があったとはいえ、入社前にはHeroku上にRailsアプリケーションを乗せるくらいの経験しかしたことがなく、Webアプリケーションがリクエストを処理する仕組みやネットワークの仕組みなどは、全く理解していない状態でした。
更に、リニューアル後のインフラ環境はAWSを使ったクラウド上に構築することが決定されており、AWSを使ったクラウドの基礎知識も必要でした。

 インフラと言えば、どうしてもデータセンターやインターネット回線や構内LAN、サーバーやネットワーク機器周りの下のレイヤのイメージです。いきなりクラウドのある世代は、インフラのイメージが１８０度変わってしまっているんだろうと感じました。

yum -y updateは、こわい

このケースの場合は仮想環境ということで、スナップショットを取ってから適用すべきでしょうね。アプリケーションに不具合があったら戻しを行うプランとすべきでしょう。

また、rubyをインストールするだけなら、rubyをインストールするだけの作業にすればよいのに、OSのパッケージ全体をアップデートするのはリスクしかないのでは？とも思います。

また、-y付きというのは、途中の大事なメッセージを読み飛ばしたり、また途中で中止するような状況（作業中に地震とか・・）が起こっても引き返せないなど、リスクがあります。私なら、-yはつけさせないかなあ。

なお、yum updateを定期的に行うのがセキュリティーポリシー、というのはこれは間違いではないので、是非、以下の運用手順をお勧めします。

・問題が起こっても業務影響の起きない環境（ステージング環境）を横に用意する
・本番適用前に、ステージング環境で適用テストを実施する
・適用後の動作テストは、できるだけ早く終わるように自動化するなど手順を整えておく
・本番適用は、ステージング環境で問題なく完了した後に、業務影響がない時間に実施する。また動作テストでNGだった際には、スナップショットから戻すなど、中止する方法も整えておく

そもそもカーネルはアップデートしないで、yum update -yだけするというが許されるなら、rubyだけ入れとけばよかったのではと思う次第です。

慎重に・・とは言うけれど

本番環境でコマンド打つ際に心が震えるようになったら、インフラエンジニアとしてはまずレベル１クリアだと思います。

サーバに変更を加えるコマンドはめちゃくちゃ慎重に打つ
暫くは上長に見てもらう or 上長に打ってもらう

で、上長に打ってもらってばかりいたら、成長しません。

基本は手順書を作って、上長に承認してもらい、あとはその手順書を遵守することだと思います。重要な作業の場合は二名体制で臨むべきです。そして、一つ一つの結果を注意深く見て、例外が起きたらそこで手を止めることが重要です。

慎重、というのはこれも危ない言葉です。手順をちゃんと理解していないと、そのコマンドが何をするかわからないので慎重になりようがないのです。

従って、手順書作成の時点で、慎重かどうかがわかります。このコマンドの意味は何？、と質問されてきちんと答えられることが慎重と言うのだと思います。

コマンドを打つ時の慎重さも重要ですが、実は作業実施前に９割は決まっていると思っています。

もっとベテランになると、各種障害の対応など、手順書なしでも作業しなければいけません。これは手順書無しだから慎重ではないのではなく、手順書を書かなくてもコマンドの意味を熟知しているから、そのコマンドを投入する事をリスクなくできるというだけです。ですから、知識が浅い人は、ベテランのように手順書無しでOSのコマンドをパシパシ叩くのは、とてもリスクがあるというのが私の意見です。

業務上知識が足りないから裏で勉強するというのは非常に効率的

AWSが仕事上振ってかかったら、どんな手段でもいいのでさっさと身に着けてしまえば、仕事が相当楽です。社内外の誰かに尋ねられたときに答えられないと、信用を無くします。また、各種タスクの生産性も全然変わってきます。

プライベートの時間を削ると幸福度が下がる、という見方もありますが、むしろ会社にいる時間を有意義にしたほうが幸福度が上がります。四の五の言わずさっさと身に着けてしまうに限ると思います。とくにインフラ関連は、自社だけではなく他社でも同じように使えるので、一生使えるという、相当に投資効果が高い分野です。

仕事で使う予定のない勉強は、なかなかモチベーションも上がらないのですが、筆者のように社内基盤自体がAWSになるという状況で、インフラ基盤の役割が回ってきたら、何にも優先してまず裏で勉強して、誰かに尋ねられたら、生まれる前から分かっていたかのように答える。これが王道だなあと思います。

また、資格については、私はそんなに大事だとは思っていません。10年経ったらただの紙です。むしろ勉強するためのモチベーションとして考えたほうがいいと思います。資格があろうがなかろうが、仕事はやらなきゃいけないですから。

AWSエンジニアとインフラエンジニア、という哲学的な話

最後まで読むと、インフラの話がAWSになっていて、考え込んでしまいました。

今の世の中なら、AWSだけの業務経歴であっても別の職場で活躍はできると思います。ただインフラエンジニアを標ぼうしつつ、業務経歴がAWSだけだとすると、これはインフラエンジニアじゃなくてAWSエンジニアですよね、と言ってしまうと思います。

あと20年後、どうなっているか。

ますますサーバーサイドはAWSに飲み込まれて行って、AWSエンジニア＝インフラエンジニアという世界がやってくるのか。今のところ、筆者の会社でも開発環境はオンプレミスのようですが、きっと開発環境もAWSに移行してしまうのでしょうね。

そんな会社ばかりになれば、AWSエンジニアという職制が確立するのかもしれません。

私の予想としては、オンプレは残ると思っています。データの中身によってパブリックプライベートが使い分けられ、その間をプライベート回線でつなくというハイブリッド利用が現在のトレンドになっていると思います。

クラウドサイドだけ扱うクラウドエンジニア（私もそうですが）を極める場合は、どうしてもオンプレミスの知識も必要です。完全にオンプレミスから離れたいなら、PaaS的な使い方を極めていくことになります。その時点で、インフラ屋、ではないかなとおもいます。プラットフォーム屋という言い方が近いです。

まとめ

普段、インフラエンジニアなど基盤系の職制は、なかなか表舞台に出にくいので感想を書いてみました。インフラや本番運用の世界は深くて厳しいので、ぜひ、先輩から学んでどんな現場でも活躍できるスーパーエンジニアを目指してほしいものだなあと思います。上に書いたように、AWSだけがインフラではないですし、本番運用の安全オペレーションはITILみたいなところもかじったほうが良いかもしれません。

20代の若いうちに裏で必死に勉強していれば、30代40代で活躍できると思います。インフラ関連に携わっている若い人を今後も応援したいですね（私の周りにもあまりいないので）。

新人エンジニアのためのインフラ入門 ThinkIT Books

本日早朝にGoogle Cloud Platformが不安定になっていた件をまとめる

Google Cloud Platformの話

Google Cloud Platformが日本時間の今日早朝に不安定になっていた時間があったようですね。

www.itmedia.co.jp

日本時間の7月18日の午前4時過ぎから約1時間、Google Cloud、Discord、Spotify、Pokemon Goなど、多数のサービスでアクセスできない問題が発生した。

Google Cloud Status Dashboardから状況を鑑みる

Google Cloud Status Dashboardには、直近の全サービスの状況が確認できるようになっているわけですが日本時間2018年7月18日12:30現在ではオールグリーン（Available）になっています。

この12時間で障害（Service Outabe）が発生したサービスは以下の通りです。

・Google App Engine
・Google Cloud Networking
・Google Stackdriver
・Google Cloud Support

それぞれ、障害報告を確認していきます。なお、全て原文の時間は、米国／太平洋（夏時間）から日本時間に変更しています。

Google App Engine

Google App Engine Incident #18005

インシデントは2018年07月18日(木) 04:15～05:23の間継続しました。
※原因や現象に関しては特段の記述無し

Google Cloud Networking

Google Cloud Networking Incident #18012

GOOGLE CLOUD LOAD BALANCINGが502を返す問題は完全に解決されました。
インシデントは2018年07月18日(木) 04:15～05:23の間継続しました。

orangeitems注：経緯の中に重要な文章がありました。他のサービスの障害は、グローバルロードバランサーの問題から波及しているように読み取れました。

Googleでは、AppEngine、Stackdriver、Dialogflow、さらにはお客様のグローバルロードバランサを含む多くのサービスで、GOOGLE CLOUD LOAD BALANCINGが502を返す問題を調査しています。

Google Stackdriver

Google Stackdriver Incident #18008

インシデントは2018年07月17日(水) 17:52～18:46の間継続しました。

※経緯を見ると、レイテンシーが悪化したような書かれ方です。
※他の問題とは別の話かもしれません。

Google Stackdriver Incident #18009

インシデントは2018年07月18日(木) 04:15～05:23の間継続しました。

以下の問題が発生していた模様です。

Googleは、Google Stackdriverの問題を調査しています。影響を受ける顧客は、stackdriver.com、クラウドコンソール、およびAPIを介して、すべてのStackdriverサービスにアクセスすることができません。

Google Cloud Support

Google Cloud Support Incident #18002

サポートセンターにアクセスできない。
インシデントは2018年07月18日(木) 04:30～05:10の間継続しました。

※原因や現象に関しては特段の記述無し
※多分に障害発生のためパンクしたのではないかと思われる

考察

全体を眺めると、ロードバランサーが502を返す現象が起点だったように読めます。ほとんどのサービスで使っていると思いますので、多数のプロダクトに問題が発生したのもうなづけます。地球規模でWEBサービスが影響を受けるのもクラウドならではですが、日本ではまだ深夜だったのでそんなに騒ぎになりませんでしたね。

AWSだったら、ELB（ALB）がこうなったらどうなったか・・・考えるのはやめます。。

続報あれば追記していきます。

追記（2018/7/23）

本件、Googleより報告書が公開されています。

https://status.cloud.google.com/incident/cloud-networking/18012

日本語にて、解説記事も出ています。

Google Cloud Load Balancerの障害、原因は新機能に含まれていたバグ。テスト時も導入時にも発見できず － Publickey

Google Cloudの障害レポートを読んだ - jtwp470’s blog

GCPって、どこのデータセンターのロードバランサーから拾っても、ユーザーのインスタンスは抽象化されているんですね。これは便利なように見えて、今回のように一か所バグがあると全世界で止まるという脆弱性のようにも見えます。

GFEを分割して障害が起きたとしても一定の範囲に収まるような対策も実行予定

とあるんですが、もともとなぜそうしておかなかったのか、これが「設計時に組み込んでしまう脆弱性」にあたると思います。Googleでもやってしまうのですから、インフラ技術者は事例として知っておくべきかと思います。

共有部分で、一か所停止すると全サービス停止するようなポイントは、できるだけ分割しておかなければいけません。この点については、また別記事を書きたいと思います。

Google Cloud Platform エンタープライズ設計ガイド

NECは今こそBtoC事業に取り組むべきではないのだろうか

NECの復活シナリオ

NEC新野社長のインタビュー記事を読みましたのでコメントします。

tech.nikkeibp.co.jp

「大企業病」「制度疲労」「内向きの仕事がたくさん」「古い会社と驚かれる」「権限移譲しても散々な結果に」「大反省している」――。NECの新野隆社長が日経コンピュータの取材に応じ、後悔の念を吐露した。企業トップがメディアの取材でここまで口にするのは異例だ。業績低迷が続くNECの社内で一体何が起きているのか。そして復活はあるのか。直近の取り組みと新野社長の発言から検証する。

しばらくすると有料会員しか読めなくなる記事ですので、ご興味あれば今のうちにご一読ください。

感想

既存事業の影が薄い

復活シナリオが書いてあるかと思いきや、海外事業の成長に向けて組織をリストラしつつ外部から人材登用した、以上のことはありませんでした。これだけでも大したものだ、と考えるなら浮上の目はないと思われます。前回の中計で、「改善目標は概ね順調も、想定以上に既存事業が落ち込む」って言葉もあった通り、既存事業こそ大事なんじゃないかと思っています。

日本でビジネスしたら売り上げが延ばせない、この言葉は実は思い込みで、これを言い訳にして既存事業の努力を放棄しているように思えてなりません。そうではないとすれば、なぜ既存事業のテコ入れについて何か具体的な対策が語られないのでしょうか。

思い返せば 

NECという会社がもっと元気が良かったころのころを思い出してみます。

通信ソサイエティマガジン No.15冬号　開発物語　PC-8001の開発

筆者は、TK-80、PC-8001/8801とその後のパソコンシリーズの開発に携わってきたが、本稿では当時を思い起こし、TK-80からパソコンが誕生した背景と経緯、日本初の本格的パソコンPC-8001の開発の経緯についてまとめてみたい。

本記事こそが、NECが急成長を遂げた出来事、かつ成長力の源なんだと思います。

１つ大事なことは、消費者に対して直接販売をしていること。つまりBtoCのビジネススタイルだということです。実は昨日、NECのLEDシーリングライトを買ったんですが、結構出来が良くて気に入りました。NECもBtoCを全部やめてしまったわけではありません。

PC-8001のこのビジネスはWindowsやIBM互換機により急速にクローズしてしまうことになるのですが、それでも、一度大きな成功をしたのは間違いないと思います。

しかも、この記事の中で、NECはシアトルの、当時はスタートアップであったMicrosoftと組んでスピーディーに製品開発をしているのがわかります。その担当部署は10名に満たない部署であったとあります。

今の時代であっても、これぐらいの規模感で新規事業を立ち上げ、優良なシリコンバレーのベンチャーと組みつつ、BtoC向けにサービス展開をすれば、上手くいく事例も生まれるのだろうと思います。

しかし、PC-98の大成功がバブルのように弾け、現在のPC事業はレノボとの合弁会社の株全体のうち33.4%までしか持っていないという状況です。

きっと、「黒歴史」「失敗事例」のように考え二度と思い出したくないという発想なのかもしれませんが、端から見ていると、「なぜあれだけ大成功したスキームを再び使わないんだろう」と思います。

ウインウインの関係になりそうな企業

BtoC事業を国内経由で延ばすとします。

アイリスオーヤマという会社を思い出しました。

売上推移|企業情報|アイリスオーヤマ

ここ１０年ですごい伸びっぷりですね。成長とはこういうことを言うのでしょう。

blogos.com

kaden.watch.impress.co.jp

アイリスオーヤマのビジネスモデルは、国内事業のシェア拡大です。やたら寡占状態だった国内のBtoCの家電メーカーがBtoBにシフトを進めた結果ホワイトスペースが生まれた場所に、うまく入り込んでいるのがアイリスオーヤマです。

アイリスオーヤマはBtoCをやり切っていますし、消費者の方向を向いてビジネスをしています。AIやIoTやデータサイエンスなど、様々なトピックではなく、あくまでも消費者に何を売るかを主眼にしています。

個人的な意見として、今NECが組むならアイリスオーヤマかなと思います。NECブランドでアイリスオーヤマ製品を売ればもっと広がりが出てくるのではないでしょうか。BtoCでの営業力・流通力はもはやアイリスオーヤマの方があるぐらいですしベストマッチに見えます。

まとめ

NECには、PC-8001/8801/9801がなぜあれだけ大きいビジネスになったのか、きちんとトレースをして、国内事業でBtoCで再度成功してほしいと希望します。もし社内にリソースが無ければ、業務提携すればいいのです。PC-8001も周辺機器は、いろんなベンダーからOEMして出してますよね。そのあたりのセンスが優れていたのでマイクロソフトまで抱き込めたのに・・と思います。

今こそ、BtoC、です。