トラブル対応は全く無駄
ミスリードを誘うタイトルでお送りしております。
トラブル対応は全く無駄だと思う。もちろん「トラブルが起きてるんだからトラブル対応しなきゃに決まってるだろ」といった話ではない。
いきなり話が変わるが、私の奥さんは看護師で、結婚当初私が風邪を引くと優しくしてくれるのかな？と思ってたけど、毎回どえらく怒られていた。曰く
- 風邪は基本的に予防できる病気
- なのに風邪を引くのは怠慢な証拠
- 風邪を引くと会社休まないとだし、お金も時間も浪費するので本当に意味がない
いや、全くごもっともでぐうの音も出ない正論としかいいようがない。
さて翻って、みなさん自身がおもりするシステムの健康をちゃんと見てるだろうか？
上記の言葉をシステムトラブルに置き換えてみよう。
また話は変わって、以前同僚からこんな話を聞いたことがある。
同僚「yamazさん、この会社に転職してから私は開発ばかりしてるのですが、いいんでしょうか？」
yamaz「？？？なんの話してるの？」
曰く、前職ではシステムがトラブル続きで開発リソースの4割位はトラブル対応と顧客への説明に費やしてたそうだ。それがあまりにも日常的すぎて、弊社に転職してから自身がトラブル対応をすることなく開発だけしてるのは、誰かが割りを食ってるのでは？という話だった。
この話を聞いて「トラブルは日常である」という発想から脱却してもらいたいという話をした。この「トラブルは日常である」という発想に立っている人は結構多いと思う。
「いやいや、風邪と違ってトラブルはあらゆる原因で起きるから予防は無理だよ」
まぁごもっとな意見だ。もちろんトラブルが起きる確率をゼロにはできないが、工学的に対応することでゼロに近づけることはできる。
Q.「どうすればトラブルのない堅牢なシステムが作れますか？」
— 最速配信研究会 山崎大輔 (@yamaz) February 15, 2021
A. 「トラブルは確率的に起きると理解し、ハインリッヒの法則に従って、小さく細かく対処していけば、複利効果でトラブルはどんどんなくなっていきます」
何度も聞かれまくるので、参考にどーぞ。https://t.co/rUEhjSgyXo
ここで大事なのは複利効果だ。システムはハインリッヒの法則に従ってトラブルが起きるので、全くトラブルの再発防止をしないとシステムの複雑さに伴って複利効果でトラブルが多発し始める。これは逆を言えば小さなトラブルであってもそれを重大事故の予兆だとみなし、細かく適切な再発防止策を積み重ねることで、複利効果でもってシステムはどんどん堅牢になっていくことを意味する.
トラブルの再発防止に対する考え方については上記エントリに譲るが、みなさんにおいてはトラブル対応に投入されるエンジニアリソースを始めとした各種リソースは、本来無駄なものだと心に刻み、ノートラブルで愛する人の元に怒られずに帰るようにしていただきたい。
あと私がトラブルに対して厳しい態度を取る理由もわかっていただけたかと思う（奥さん怖いよ）。
（おしまい）
【2018年版】広告システムエンジニアは絶対におもしろいと思う理由
これは Supership株式会社 Advent Calendar 2018の25日目の記事です。
Supership株式会社 CTO @yamaz です。
という記事をちょうど10年前に書きました。
今回はあれから10年経って現在広告システムエンジニアをとりまく環境ははどうなっているかについて書きたいと思います。
TL;DR (３行で)
- 10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域だよ。
- 広告テクノロジーをプレイヤーが切磋琢磨し続けてきた結果、大規模配信・集計技術もさることながら大規模データ分析や運用技術の領域も大事になってきたよ。
- まだまだ課題満載な業界だけど、デジタルマーケティングに未来を感じてる人はぜひ広告業界へ応募を！
10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域である
10年前はユーザのリクエストに対して手元のDBにある広告返すだけのシステムだったが、現在はプログラマティックバイイングという仕組みでリアルタイム（100msec程度）に広告在庫をオークション形式で買い付けが完了するようになった。またアクセス数も10年前は弊社が配信する配信量はせいぜい月間数億アクセス程度だったが現在は月間数千億〜くらいの規模になっている。
実際のところこの規模のアクセスをさばくのはクラウド全盛の現代においてはそこまで大した話ではない。だけどビジネス的にとても大事な「より安く」という条件が加わるととたんに難しくなる。「早く、安く、うまい」を成立させるためにはOS/ネットワーク/アルゴリズム/各種実装技術の詳細などのコンピュータサイエンスでの知識にとどまらず、機械学習的なアプローチも当然組み入れることになるので、大学で学んだであろうほぼすべての知識を要求される。
このあたりは10年前と変わらず引き続き面白い領域だ。
データ分析と機械学習の台頭
広告テクノロジーを持つプレイヤーがこの10年切磋琢磨した結果、大規模配信と集計技術はかなりコモディティ化してきた。これをもって「アドテクは死んだ」という人もいる。だけど配信・集計技術はあくまでもマーケティングを達成するための手段であって目的ではない。これでやっとマーケターの人たちにデジタルマーケティングをしてもらうための下地が固まってきたと考えるのが正解だと思う。
その結果としてデータ分析というジャンルが出てきた。かつては分析というとせいぜいクリックデータなどの時系列分析程度だったが、機械学習による推定技術の発達によりユーザの属性分析などの高度な分析が可能となってきた。
このあたりいわゆる機械学習やデータマイニングの分野だが、この分野はしかるべき量の生データがないとどうにもならないけど、その点データはあきれるほどあり、退屈することはないと思う。
広告運用技術の発達
10年前広告システムと言えばざっくりヤフーとGoogleとその他ちょっとしかなかった。だけど現在は
ヤフー
Line
Criteo
その他DSPなどなど
少し大型のデジタル広告をしようと思うと20くらいのシステムを使う必要がある。その結果として実際の入力オペレーションやレポーティングが非常に煩雑になってきた。
我々はマーケテックと呼んでいるが、このような煩雑な広告オペレーションを楽にするための技術投入は上記のアドテクなどに比べてほぼ行われてないと言ってももよく、
まさにこれからでやりがいのある分野だと思う。
終わりに
以上広告システムがいかにおもしろいかを述べてみた。たいていの人は広告システムというものをまじめに考えたことがないと思うので、興味を持った人は候補の中に入れてみてください。興味がある方は「話を聞きたい」というようなレベルでも構わないので、
https://www.wantedly.com/companies/Supership
あたりから応募をしてほしいです。
あわせて読みたい：
Supershipでは広告技術もですが、検索技術にも力を入れています。
検索技術も広告技術と並んで技術的、学術的、ビジネス的に面白い分野なので、興味ある方は合わせてどうぞ。
検索サービス開発が絶対におもしろいと思う理由【2018 改訂版】
【おまけ】デジタルマーケティング業界の残念な部分と、だけど未来は絶対にあるという話
ここまでかっこいいことばかり書いてきたけど、私がデジタルマーケティング業界にいる中で少し残念に思っていることを書きたい。
それは転職ドラフトというサービスでレジュメを書く際に「避けたい分野」として他ジャンルに混ざって「広告」がそこそこ選ばれてる現実があるということだ。
これはデジタルマーケティングに20年ほど関わっている私にとってかなり寂しいことで、これは避けようとしている応募者の方に問題があるわけではなく、業界側に原因があるという理解です。
転職ドラフトで避けたい分野としてわざわざ「広告」を選んでる人はおそらく今もしくは過去に広告業界に在籍した人の可能性が高いと思っています。
おそらくはデジタルマーケティングの業界に希望を持って飛び込んできたものの、
- アクセスが実際殆ど無い
- システムを触らせてもらえない
- 触らせてもらってもデジタルマーケティングとは言えない雑務ばかり
- そもそも技術者がいない
- 儲けのために非倫理的な業務をさせられる
など色んな理由で期待を裏切られて幻滅したとかそんな理由だと思う。
だけどそれはその在籍した会社の問題であって、全部の会社がそんな会社ばかりではなく、うまくやっている会社は存在するというのは知ってほしいと思います。
オンラインメディアは「OneToOneターゲティング」を「リアルタイムレスポンス」で可能とする唯一のメディアであり、その収益を支えるデジタルマーケティング領域は今後伸びる一方で下火になることはほぼありえません。
ですので、もしあなたがデジタルマーケティング業界の未来に希望を持っているのなら、他の業界に行く前にうまくやっている会社を受けてほしいと切に思います。また弊社はその一社であると断言します。
せっかく希望をもってこの業界に入ってきたのに、うまくやってるところを知ることなく去ってしまうのは本当にもったいないことなのだから。
（おしまい）
平文のTCP/IPにおいて転送されたデータの信頼性を期待してはいけない
TL;DR 平文のTCP/IPの通信では送信したデータの完全性は期待できないので、経路にはSSL/TLSを使いましょう
TCP/IPはUDPと違い、信頼性のある通信を実現するためのプロトコルという説明がよくされる。なのでTCP/IPでやり取りしたデータは1bitの狂いもなく転送先に届くと思われがちだ。TCP/IPが信頼性のある通信を確保してると言われているのは下記の理由による。
1. データが届かなかった場合の再送処理がプロトコルに入っている
2. TCPパケットにペイロードのチェックサムがあり、不具合が検知されると修正もしくは再送される(ただし16bit)
3. IP層の更に下の層にチェックサムがあり、不具合が検知されると修正もしくは再送される(イーサの場合32bit)
しかしチェックサムはそれぞれ16/32bitのため、昨今の超大量データを取り扱うにはかなり心もとない。
1. ざっくり1600万〜100億パケットに1回の確率で検知できないエラー(データ化け)が起き得る
When the CRC and TCP checksum disagree
2. 数百ギガバイトのインターネット経由の転送でデータ化け
2005-01-30 - 登 大遊＠筑波大学大学院コンピュータサイエンス専攻の SoftEther VPN 日記
10年ほど前はIPより下の層は技術向上によりどんどん信頼性が増すものだと思っていたけど、技術革新が故にモバイルや衛星間通信など今まで信頼性を確保できなかった領域に物理層が拡充するようになってきて大分怪しくなってきたと思う。
というわけで平文のTCP/IPにおいて転送されたデータの信頼性を期待してはいけないことは理解してもらえたと思う。ではどうすればいいか？その答えはSSLを噛ませば良い。
「SSLは暗号化の技術なのになんでデータの信頼性に関係あるの？」と思うかもしれない。SSLには暗号化を行って第三者からデータを秘匿する機能の他に第三者によるデータ改ざんを防止する機能もある。
データ改ざんの防止
→データが改ざんされることなく届く
→データの信頼性の確保ができる
というわけだ。TCP/IPの上位にさらに改ざん防止がつくためTCP/IPとは比べ物にならない信頼性を確保できる。
# SSLの改ざんに対する強度についてはちょっと力尽きました。誰か教えて。。
今回職場でストリーミング処理基盤の話をしている際、違うチームで同じ話になったり、いくつかのストリーミング処理基板の初期実装で転送部分がSSL非対応だったりしたので、もしかしたらこれは一般的に知られてる話ではないのかもしれない。
「インターネット越しの通信は盗聴がやばいからSSLにしとこう」ということでSSLにしといたので意図せずデータが救われてるケースもあるが、データセンター間の専用線の場合「秘匿の必要がないから平文で大丈夫」と考えるのはとても危険な考え方だと思う。
莫大なデータをやり取りするようになった昨今、TCP/IPは信頼できると無邪気にインターネット越しにデータ転送してたら実はデータが壊れてたみたいな話は今後ありそうなので、気をつけていきたい。
（おしまい）
