アラートの指針

My Philosophy on Alerting - Google ドキュメント

http://robewaschuk.tumblr.com/post/48822960728/my-philosophy-on-alerting

My Philosophy On Alerting

元 Google "Site Reliability Engineer" で現 Tumblr？ の著者 Rob Ewaschuk による、サービスモニタリングとアラートに関する原則。

• アラートによる呼び出し（page）は以下の要件を具えていなければならない。
  • 緊急のものであること。
  • 重要なものであること。
  • 行動を起こすことが可能であること。
    • 知性が必要なものであること。機械的対応でよいのなら、アラートは無意味。
  • 現実に則したものであること。
• 現在サービスに起こっている・起ころうとしている問題をあらわしていなければいけない。
  • 起ころうとしている、というのは冗長性がなくなった、などの状況。
• ほとんどの問題は以下に分類できているはず（以下に分類できるような問題を扱うべき）:
  • 可用性と基本的な機能
  • レイテンシ
  • 整合性
  • サービスや機能に特有のもの
• 症状（symptom）ベースで問題を把握することで、一貫性を保ち、ロバストに把握することができる。
  • 原因ではなく症状に基いてアラートを投げ、原因はアラートの情報に含めるようにする。
    • ユーザの観点から監視する。データベースが落ちた、などの事情はユーザの知らないこと。
    • また、原因の監視ではユーザに本当には影響がないものを誤ってアラートしてしまうこともある。
• 今すぐでなくてもよいが、早めに対処されたいクリティカルではないアラートをどう扱うか。
  • バグトラッキングシステムに登録する。
  • デイリーレポートを送信するようにする、など。
  • 日々のワークフローに組み込むことが大事で、IRCやメールへの通知だと埋もれてしまう。
• 監視ルールを作ったら、それがどう対処されているか追跡すること。人間が確認して問題ない、としている割合が高かったら何かおかしいかもしれない。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~

Scala の機能がコンパイル速度に与える影響

compiletime というプロジェクトで、テストライブラリの選択や Scala の機能がコンパイル速度にどのように影響を与えるか計測した話。著者は ScalaTest の作者なので何かしらバイアスがかかっているのかもしれないが、（specs2 が遅いという）結果には体感的に納得感がある。

• JUnit、TestNG、ScalaTest、specs2 が対象。
• コンパイルが速い順番に JUnit、TestNG、ScalaTest で、specs2 はとても遅い。
• コンパイル時間は以下に影響を受ける:
  • スコープ中の implicit の数
  • by-name パラメータの数
  • テストクラスのメソッドが trait によって提供されるか、親クラスから継承されるか
• implicit に関しては、スコープに import された implicit の数とスコープ中の implicit の使用の数の積に依ると思われる。Scala コンパイラがコンパイルエラーを発見したとき、スコープ内の implicit を見ていくが、都合のよい implicit を発見しただけでは終わらず、残りの implicit もぜんぶ舐めて他に合う implicit がないことを確かめる必要があるからだろう。
• by-name〔ってのは specs2 でいうと "..." should "..." in につづくブロックのようなアレのことだろう〕だけでなく関数リテラルにも影響を受けそうだとあるが、きちんとした検証はしていないとのこと。
• Scala 2.10 から scala.reflect.runtime.universe を用いてスコープ内の implicit をカウントできる。
• グラフは上から順に、
  • テスト数を変化させながら、ScalaTest で assert(_ === _) を使用した場合、import ShouldMatchers._ した場合、with ShouldMatchers した場合のコンパイル時間。
  • 同上。
  • 各フレームワークで最速の方法を使った場合の、テスト数に対するコンパイル時間。ScalaTest は Spec、specs2 は mutable.Specification を使っている。
  • specs2 の記法に近いスタイルを採用したときの、テスト数に対するコンパイル時間。specs2.Specification が途中でガクッと落ちているのは OOM になるかららしい……。
  • 同上、縦軸は生成されるクラスファイル数。
  • 同上、縦軸は生成されるクラスファイルの総サイズ。

この結果をもとに、ScalaTest をこのように改良する方針だ、という話も書かれている。その他詳しい数字は原文を参照されたし。

Scalaスケーラブルプログラミング第2版

エンジニアの導入・教育・指導について

Technical onboarding, training, and mentoring - GoGaRuCo from Kate Heddleston

各所で何度か話されているらしいプレゼンテーション。動画は RubyKaigi のもので、スライドは Golden Gate Ruby Conference のもの。

オンボーディング（Onboarding）ってのは組織やチームの外の人を定着させるプロセスのことで、タイトルではわかりやすく導入としたけど、以下はそのままオンボーディングで。

• オンボーディングの目標。こんな人に育てたい。
  • 生産性が高いこと。
  • 自立していること。他の人に頼らなくても自分で仕事をこなせる。
  • 自信を持っていること。自信をそなえている人は生産性も高い。
    • これが一番大事。
• オンボーディングによる恩恵の側面。
  • 個人。チームの一員となっている自覚と自信を持たせ、定着させる。人が辞めることのコストは非常に大きい。
  • 会社。組織が大きくなるにつれ生産性が下がる、とならずその逆を行くためにオンボーディングを行う。
    • チームの負債（Team debt）。技術的負債のように、オンボーディングを怠ることはのちのち大きな負債となる。
  • チーム。とくに小さなチームでは新たな人が入るたびにチーム自体が変わっていくので、オンボーディングのプロセスを確立しておくことでみなが同じ方向を向いていられるようにする。
  • ダイバーシティ（ジェンダー・人種など）。組織はともすれば同じ文化、同じ価値観の人で凝り固まってしまう。オンボーディングによって、既存のそれとは異なるカテゴリに属する人も受け入れられる余地をつくる。
• 導入の要素
  • 誰が。基本的に誰でもいいが、直近でオンボーディングを受けた人であれば相手の気持ちを想像しやすいのでよいだろう。
  • いつ。加入が決まったあとならいつでもだけれど、オンボーディングの終わりは自立したメンバーに育った時点。
  • どのように。やる気のあるメンターは導入期間中ずっと相手につきっきりでいよう、などと考えてしまいがちだがこれでは疲弊してしまう。よい方法として、新人が危険なところに触れないような遊び場を作って、そこで自由にさせる。メンターは必要なときに質問に答えられるようにしておく。
• 行うこと、教えること
  • 技術的な知識。これは本でもネットでも教えられる分野なので、そう重要でもない。
  • 社内の知識、プロセス。これは重要。自立したメンバーの育成のために必要だが、明文化されていない知識も多い。
  • 自己啓発。
• 4週間のオンボーディングの例。
  • Week 1
    • 開発環境の構築。最後にこれを受けた人がやるとよい。
    • 小さな変更を出荷させる。テストの修正とか。
    • 学んだことなどについて、日誌を書く習慣をつける。
    • ソーシャルイベント。名前と顔を一致させ、質問しやすくする。
  • Week 2
    • 会社の歴史について学ぶ。誰がどんな理由で始めたのか、などなど。
    • チームの地図（顔、名前、どんな仕事をしているか）を知って、チームメンバーと話す。
    • コードに関する勉強と実習。［Code Labs］
    • 先輩エンジニアについてどんな風に仕事をしているか学ぶ。［Shadowing］
  • Week 3
    • この頃には自立しはじめているはず。
    • メンター・上司との1対1の面談をし、目標設定とフィードバックをおこなう。
    • プレゼンテーションをさせる。技術的なトピックについて他の人と議論する。
  • Week 4
    • 先輩エンジニアに補助されながら、より大きなプロジェクトを進めていく。
  • それから先
    • 技術的な見習い期間をもうける。詳しい先輩について学ぶって感じかな。
    • 成長を見守る。

DevOps: 健康な基盤のための 12 のチェック項目

A Healthy Platform Checklist

いわゆる devops （platform engineering と呼んでいる）において、インフラ自体をひとつのプロダクトとみなして他のプロダクションチームに、一貫したやり方で提供することに価値があると筆者はいう。そして以下はこれに関して見聞きしてきた知見をまとめたチェックリスト。ただしこれをすべて守ることが必要だといっているわけではない。特にスタートアップを念頭に書かれていて、早めに基盤の構築に投資しておくことを薦めている。

• 1. システムがコードによりプロビジョニングされている。
  • このリストの中でもイチオシ。
  • ハードをセットアップする時間を節約し、システムの他の部分を組み立てるための部品を手にすることができる。
• 2. フィーチャーチームに配属されているエンジニアはプロダクション環境を触る権限がある。
  • プラットフォームチームがプラットフォーム自身に忙しかったら、他のチームの面倒を見ている余裕はないはず。開発チームにツールや権限を渡し、どうしても必要なときに呼んでもらうようにする。
• 3. プロダクションのアプリケーションは Twelve-Factor App である。
• 4. 監視とアラートの設定は集約化されていて、必要なら簡単にアクセスできる。
  • 開発者の速度向上と、システムのドキュメント化のため。アラートはシステムのどこに問題があるかを明確にする。
• 5. システムは人の手を借りず自動的に異状から復旧する。
  • まともなシステムであれば復旧方法は if-then で表されているべきで、そうであれば自動化可能なはず。
  • もし自動化できる範囲を超えて人間にメールを送る場合は、何をすべきかではなく、何が行われたかを情報として含める。
• 6. 毎日の管理タスクは自動化されている。
  • さらに進んで「開発者がプロダクションに SSH する必要があってはいけない」という話もあるが、筆者はここまでは求めない。
• 7. 設定データは中央リポジトリに置かれ、アプリケーションは最新の設定を反映する。
  • これの実現はデプロイ環境によりまちまち。
• 8. 開発環境はプロダクション環境を反映している。
• 9. アプリケーションはデプロイ先の環境に依存しないランタイムを提供される。
  • 長年動いているアプリにどれだけパッチが当てられているか誰にも分からないとか、デプロイ環境に置いてあるファイルが実は利用されているとかいうのはホラー。
• 10. ひと月に一度以上デプロイされるシステムはコーヒーを淹れるよりはやくデプロイできる。
  • デプロイして確認するのに発生するインタラプトはバカにならない。
  • 何かあった時にすぐに直せるというのは大事なセーフティネットである。
• 11. 開発環境はプラットフォームチームのプロダクション環境である。
  • プラットフォームチームが気にかけなければならないものがプロダクション。
  • ここに不整合が起きるとプラットフォームチームのプロダクトへの信頼が損なわれてしまう。
• 12. プラットフォームチームは現在のニーズのみならず、将来におけるそれをも考慮にいれる裁量をもつ。
  • スタートアップの最初期ならばこのリストに従っている必要はないが、将来組織が拡大してもそのままでいてはいけない。
  • 早めに投資しておくことで、生じうるコストを小さく抑えることができる。

ひどい原稿からはじめる

Shitty First Drafts

『Bird by Bird: Some Instructions on Writing and Life』という、書くことについて書かれた本の断章。プロでもはじめからよいものなど書けないのだという告白であり、文章を書こうとする人を励ましてくれる内容のようだ。この本自身も良い本のようだけれど、残念ながら日本語訳はない。

• どんな文章の名手も、最初の原稿はひどいもの。
  • 優雅な気分であふれ出る才能を感じながら書いているわけではない。
  • 筆者の知るある書き手は毎朝自分に向かって、「選択肢がないってわけじゃない……書くか、自殺するかだ」
• 最初の原稿ってのは子供のそれ。
  • 誰も見ない。好きに書いたらいい。
  • 理性的な頭では書けないようなものを書いてみる。
  • 6ページ書いて最後の最後に自分でも予期しなかったものが現れるかもしれないし、それはそれまでの5ページ半がなければ到達しえなかったものだ。
• 筆者がフードレビューをしていたときの経験。
  • やはり恐慌におちいる時はあった。そんな時にも結局、ひどい初稿を書く、というところに落ち着く。ただ指を動かしてタイプする。
  • 翌日、何とか使えるところを探しだす作業に入る。
  • こんなことを毎月繰り返している。
• 良い文章というのは最初のあがきから始まるもの。とにかく紙に書かれたものからはじめる。
  • 最初の原稿は "down draft"、ただ書き留める（get it down）だけ。
  • 次の原稿は "up draft"、修正する（fix it up）から。
  • 三番目の原稿は "dental draft"、ひとつひとつ、まずい点がないかチェックする。

具体的なエピソードについては原文を参照されたい。

SaaS: プロダクトが勝手に売れるのにまかせようとしてはいけない、セールスせよ

If SaaS Products Sell Themselves, Why Do We Need Sales? | Andreessen Horowitz

ベンチャーキャピタルのブログなので、エンタープライズ向けに SaaS を売ろうというベンチャーに向けた文章。SaaS のセールス方法について。

• 課金前に無料で試用できるフリーミアムモデルの隆盛から、SaaS プロダクト自身がその販売促進になっているという考えが流行っているようだが、筆者はそれは間違いだと考える。
• エンタープライズ向けセールスの役割は、顧客企業の内部の購買プロセスの助けをしてやることだ。
  • 顧客の知らなかった新たな価値を伝えてやる必要がある。とうぜん予算枠などがあるわけではない。
• SaaS プロダクトの導入を決断させるには、「Why buy」「Why you」「Why now」の 3 ステップがある。
• Why buy: そもそもなぜプロダクトを導入するのか
  • まず自分たちを理解してもらう前にこちらが顧客のビジネスを理解し、それに対して自分たちのプロダクトがどういう価値を発揮できるのかを提示する。
• Why you: なぜ自分たちのプロダクトを選ぶのか
  • 競合との比較を行うステップ。
  • その際ビジネスのレベル・アーキテクチャのレベル・機能のレベルの 3 レイヤがあり、それぞれ会社の中の違った層に響く。
  • 競合とは別のスタートアップだけでなく、オンプレミスのパッケージ、内製の手法、中堅ベンダーによる製品などもそれに含まれる。
• Why now: なぜ他の分野に投資するのではなく今なのか
  • 自分たちの価値を定量化して提示するステップ。
• SaaS は勝者の総取り（winner-take-all）市場であり上陸と開拓（land-and-expand）戦略が必要だが、上陸すれば開拓できるというものではない。
  • 顧客の開拓に投資し、顧客を味方につけることができれば、製品の販売にもつながるだろう。

Go はショップ製の治具（ジグ）だ

Go Is a Shop-built Jig - Cocoaphony

• ここで "Shop-built Jig" と呼んでいるのは、様々な問題に対して汎用的に適用できるよう用意されたツールの逆のコンセプトで、狭いけれども実践的な目的にあわせて作られた小さな道具のことを表している。
  • 治具とは - 大車林 Weblio辞書
• Go は現実的な問題を解くことしかできないので、スペック不足に思えてしまう。
• 筆者は当初はジェネリクスのないことに不満を持っていたけれど、問題を抽象化しようとすること自体 Go の目指す所ではない。
• 美しい道具をどう使うか悩むのではなく、問題を解決するコードをそのまま書くのが Go 流。（さらに gofmt を使えば、誰が書いてもほとんど同じようなコードになるだろう。）

なるほどねーって感じ。こういうやり方が気に食わないって人はそれはそれでいるだろうけれど、Go のポイントは抽象化しなさにある、というのはしっくりくる。

あわせて読みたい

Go: チャンネルは不十分―なぜ pipelining がそれほど簡単ではないのか - tl;dr