何気ない記録

なんとなく自分の意見を書き記すときにつかいます。つまり不定期更新です。

個人的にはゼロ点の報告です

 

CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog

その認識ではダメよ。そもそもコレはインフラ設計時点でのミスで切替作業には関係ない。選定時点で仕様に違いを認識できておらず、且つ、その状態で変更手順やテスト手順を作成した事が原因。それでも普通は発覚する

2017/06/23 12:52

 

うちのチームでこの報告だとゼロ点です。

 

理由は2つ。

 

まず、そもそも移行先選定時点でCDNの制御方式を含む違いを的確にレポートし、その評価が行えていないわけで、そもそも切替時点のミスではない事。

 

次に、そもそもですが、CDNを含む仕組みであればキャッシュコントロールというは基本中の基本で、どのような移行であれ、キャッシュ制御が正常に行われている事は確認します。

つまり、仮にCDNの制御方式の違いを認識できていなかったとしても、本来CDNを利用する仕組みで一般的に行うべき評価を着実に行っていれば、少なくともProduction環境でしか、つまりぶっつけ本番でしか発覚しないとしても、お客様からの指摘がある以前に切替直後に自社で状況を認知でき、直ぐに対応を開始できたはずなのです。

 

結局、切替時云々というよりも、1つは根本的な設計ミスにより発生した問題で、2つめは運用管理上の問題であったというだけです。

 

で、その部分が正しく評価できないというのは何が問題かというと、原因と対策が正しく認知・設定できていないという事なんですよ。

 

CDNについて「は」今回の対策でもしかすると良いかもしれません。

が、本質は設計時点のミスがテスト工程でも発覚できないという現状の運用や体制であって、人的ミスは基本起きうるものなので、如何にその部分を仕組みで軽減するかというのが必要なわけです。

 

例えばそれは、新しい技術や設備を選定する場合は、そういった諸元のようなものが確実に選定作業中に確認できるようになっているであったり、選定メンバーにはそういった人材が正しく選ばれており、運用サイド、開発サイドそれぞれの立場から正しくレビューできているであったり、そういったプロセスが回っている状態を作る事が大切です。

 

また、テストやチェックも同様で、自社が採用している技術がどのように組み合わさっているのか、その点を理解すれば自ずとこういったテストケースは明確になります。

 

通常、ローカルキャッシュであってもアプリケーションレベルのテストでは当然正常な情報が表示されているのかという点が含まれています。

それはただ単純に表示すべき情報が正しいのか?という事だけではなく、ヒット率は想定通りであるのか?であったり、効果が適切にあらわれているのか?という事であったりと、実際にはチェックポイントは複数存在します。

 

つまり、キャッシュ機構を使うテストとして必要なものが含まれていないという事が問題で、それが着実に実装されていれば本来は人的ミスがどこかででてきてもちゃんとストッパーとしての役割を果たすのです。

 

これは当然他の実装にも関わっていて、キャッシュ機構以外にもWebサービスでは様々な仕組みを用いて高速化であったり、管理の効率化を図っています。

そのようなものを人間が逐一理解し把握、適宜手動で確認をするというのは現実的に限界があるわけで、素考えると「仕組み」としてのそういった取り組みが存在しないという事が本質的な問題であって、点のフォローをすればよいというものではありません。

 

システムに完璧というものは絶対にありません。

人間の行う事にも完璧というものは絶対にありません。

そして、ミスや失敗は行為は問題であるものの、それ自体は誰がやっても発生する可能性はゼロにはならないわけで、起きた事は悔やまれますが、そこから正しく学び、それに正しく対応する事が重要なのです。

 

そう考えたとき、原因の認知と対策の検討がズレているというのは、発生した問題の影響よりも、システム・サービスとしての脆弱性を如実に表すモノで、技術的な視点でみると、この報告書の方が僕は非常にミスが多いと感じます。

 

詳細(この報告では行った事の事実を列挙しているに過ぎませんが)を報告する事は良いことですが、当然それは正しい認識と正しい対応が揃わなければなりません。

 

一般の利用者としてこのドキュメントを見る人は「そういうことなのか」程度で突っ込む必要もないとは思いますが、技術者としてこのドキュメントを評価する人は、これは本当に根本原因なのか?という視点でちゃんと評価できないと、それは貴方自身も同じミスをする体制を手元に構築している可能性があるという事です。

 

そしてそれは、貴方自身だけの問題ではなく、もしかすると組織・チーム全体の問題にもなりかねません。

 

技術とは小さな複数の技術の集合体であり、サービスとはそういった技術の集合体です。

 

技術者が行うべき事は、そういった集合体を、いかに正しく、いかに効率的に運用するか、運用できる環境をつくるのか、その手段が例えばプログラミングであったり、基盤の選定であるわけです。

 

ですから、集合体を正しく管理するという視点で見ると、プログラミングミスも、設計ミスも、オペレーションミスも、規模や影響は違えど同じミスであって、原因は大抵の場合は似たようなものなのです。

 

この視点が持てれば、極論言えば、テスト工数を多少削減したとしても、設計であったり、レビューであったり、様々なところで予防的なプロセスが働くようになり、負担を軽減しつつ、効率的な運用や開発が行えるようになります。

 

コメントを眺めていると、記述されている事の本質についてあまり理解していないような気がしましたので、あくまでもただのいち技術者としての視点・意見ではありますが、単純に「いいね」とする話でもないよ、と言わせていただきました。