kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

「OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法」感想

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法 | クリスティーナ・ウォドキー, 及川 卓也(解説), 二木 夢子 |本 | 通販 | Amazon

死ぬほどひどいタイトルにドン引きしてこれがおおよそcannonicalな本であることはわかっていたにも関わらず別の本に逃げていた。

今、どんなタイトルからこんなひどいタイトルの本にしてしまったのか原書を調べていたのだけど原書のタイトルは大きく違った。

Amazon.com: Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results ( OKRs ) eBook: Christina Wodtke: Kindle Store

Radical Focus, 徹底的な集中。たしかにこのほうがこの本で言いたいことの本質を捉えている気がする。 これにOKRとタイトルを付けるのはわかりやすいかもしれないけどまさに目的より手段を優先することを冗長していないだろうか。

閑話休題、結論から言うとけして悪くはないと思う。 序盤の小説仕立てのところは触りとしては悪くない。 もうちょっと間間に挟んでくれるともっと読みやすかった気もするが、そこまでするほどでもない気はする。

後半を非常に駆け足で読んだのでそこは再度読み直したほうがよいかも。

あと、このOKRをボトムアップでやるのはあんまり有効ではないなと思った。 この中で説明されているように基本的にOKRはトップダウンだと思うので1チームで導入しようとしてもひとつ上の枠組みで目指すものとの整合性が取りにくい。 もしひとつ上の枠組みでOKRではなくMVVのようなものが設定されている場合、MVVからOKRへ落とすような工夫が必要になると思う。

4セルでキープする項目を書くのは良いと思った。 OKRやKPIで、じゃあ目標だけおっていればいいのか、他のことは後回しでいいのかっていう話に良くなったので。

bastionを廃してRDSのパブリックアクセス可能(publicly accessible)を有効にしてはどうか提言

tl;dr

  • Site to Site VPN, Direct Connect, Client VPNなどでオフィスネットワークとVPCがつながっていない前提
  • 従来Bastionインスタンスをおいていたがモダンな設計ではもはやRDS以外で使われない
  • publicly accessibleがtrueでもセキュリティを担保しやすくなっておりメリットも多いのでそうしたらどうだろうか

BastionがもはやEC2インスタンス用でいらない背景

elpy1/ssh-over-ssmやEC2 instance connect, そもそもECSやEKSの場合は個別のノードへログインする必要性がない、などの背景でモダンなAWSアーキテクチャではEC2インスタンスへのログインのためにbastionはほぼほぼ不要になりつつある。

bastionを使うとbastionに秘密鍵をおいてしまったり退職者のユーザーアカウントがなかなか削除されなかったりいつの間にかそこからデプロイされるようになる = immutableではなくなり作り直しができなくなる、などの問題があるためむしろ積極的に避けたい。

public accessibleをtrueにする利点

  • メリット
    • 設計がシンプル
      • RDSを知っている人なら誰でも接続方法がわかる
      • 部署やシステムごとに接続方法が変わったりしない
        • 接続方法のドキュメントをメンテナンスしたりその場所を考慮したりする必要がない
    • 余計な経路がないので可用性が高まる
      • bastionの可用性を担保しようとすると冗長化などでかなり構成が複雑になる
    • bastionで余計なコストが掛からない
    • mysqlクライアントから接続するときにssh port forwardingなどの設定が不要
      • 設定が難解で動作確認も難しいので非エンジニアにもやってもらうのがキビシイ
    • ssh port forwardingやbastionサーバをサポートしていないmysqlクライアントでも接続可能

publicly accessibleを有効にするリスクは幽霊では?

RDSでpublicly accessibleがtrueであることがセキュリティリスクである、ということはAWSを使う者にとってある程度の共通認識である。 しかし、これがどうにも疑わしい。 bastionを経由しようが結局public IPアドレスが振られるのがRDSインスタンスからbastionへ変わっただけで実態的なセキュリティリスクは減っていない。 確かにMySQLなどはプロトコルがセキュアでなかったりsshより比較的簡単なIDパスワードが使われる傾向がある。しかしIAMデータベース認証ではセキュアプロトコルが強制されるしセキュリティグループなどで接続元を絞れば十分安全である。またパスワードはそもそも十分セキュアな文字列にするべきだ。

これは個人的な推測なのだがどうにもpublicly accessible有効が危険だという認識は極めてずさんな設定のRDSへ攻撃された事例や話から生まれている気がする。実際の事例を聞くと安易にpublicly accessibleを有効にしたRDSインスタンスでsecureでないrootアカウントを設定してrootアカウントのユーザー名も"root"のままにしていたような、そのような話しかない。 確かにpublicly accessibleをfalseにすれば攻撃の難易度は上がるがDBインスタンスへのアクセシビリティを犠牲にしているので一概にやるべきとは思えない。

上記を踏まえてのpublicly accessible: trueでのおすすめ設定

  • (must) publicly accessibleをtrueにする
  • (must) セキュリティグループでingressをオフィスゲートウェイ(+ VPC)に絞る
  • (must) アプリケーション用パスワードは十分セキュアな文字列にする(パスワードジェネレータなど推奨)
  • (must) インターネットを経由する接続には必ずSSLプロトコルを利用する
  • (should) 開発者の接続はIAM データベース認証 - Amazon Auroraを使う
    • 必然的にプロトコルSSLになるためインターネット経由の接続でも通信内容が漏れる心配がない
  • (may) 接続ポートをデフォルトから変える1
    • 安易な攻撃からの防御手段になるがポートスキャンなどで無意味化される。本質的な対策ではないかも。

残タスク

publicly accessibleを有効にした場合、果たしてもはやprivate subnetは必要なのかという疑問が湧いてくる。 現段階ではもはや必要ない気がする2。ここについては追加調査が必要。


  1. 変える場合は変更先のポート番号などに特にコンベンションなどなさそうなので(TCPやUDPにおけるポート番号の一覧 - Wikipedia)雑だが1万番代のポート番号からランダムで選択などでいいと思う。特にRDSは独立したインスタンスなのでポート番号がかぶる心配はない

  2. GCPとかそもそもVPC概念薄いが運用上問題になる話はほぼない。あっても既存の運用を変えずにGCPへ持っていきたいというケースしか聞かない

【WIP】slackでイケてないと感じる点リスト

  • スレッドが使いづらい
  • 複数のチャンネルやスレッドを同時に開きたいのにできない
  • チャンネルへの入退室がログに残る
    • 設定から非表示にできるがデフォルト非表示でいい
  • 各種改善の速度が遅い
    • 予約投稿がAPI的には実装されたのに半年以上UIが用意されない
  • 議論がググれない
  • 内容をpublic webに公開できない
  • エセmarkdown
    • そのWYSIWYGが壊れている(特に日本語入力が絡むと)
  • TBL

「本気でゴールを達成したい人とチームのための OKR」感想

OKR本がいくつか選択肢がある中で一旦読みやすいものをと思って日本人が書いた本を手に取った。

最初の方の筆者の個人的な経験が冗長かつ根拠のない説教を聞かされている感じで辛い。 うざい上司に仕事論を聞かされている感じでなるほどtraditional japanese companyではこういったことを飲み会で聞かされるんだろうなと思って飲み会参加したくない感が高まる。

後半は具体的なOKRの運用や概念に近づくのでだいぶマシになったが、おまそうかもしれないので改めて別の本を読んで裏取りしたほうが良さそう。

結論: 最初からcanonicalなOKR本を読んだらよかった。

「階層脳」を使って自分の改造構造・タグについての考えを整理してみる

きっかけ

以前から僕は階層不要説に懐疑的だったのだけど、ふとそのことについてつぶやいたらscrapboxの開発者の人がそれに反応してくれた。 いい機会なので記事分類手法における階層について僕が思っていることを書く。

階層脳に対する反論

scrapbox.io

この記事は反階層主張の中でもかなり有名だと思うのだけど(かつ上記の反応してくれた人の記事でもある)、 ちょうどいいのでこれを題材にして僕の考えを浮かび上がらせようと思う。

以下上記記事中のトピックとそれに対する僕の意見を書く。

階層的管理の失敗

たいてい途中で破綻する

大筋同意だけども、僕が見た破綻は以下の2パターンでどちらも階層構造固有とは言い難かった。

  1. 新たなコミュニティの参加者が階層構造を把握せずroot直下でページを作ってしまう
    • scrapboxでもリンクを貼らなかったりすでにあるハッシュタグを使わずページを作ると結局同じ
    • つまるところオンボーディングの問題
  2. 階層構造を変更したい人間が従来と異なる階層ルールを導入して新旧ルールが入り混じり、その結果ルールが崩壊する
    • きちんとコンセンサスを取らないことが原因
    • また階層構造変更の提案が通りにくい遠因として構造を変更するとリンク切れを起こしたり、そもそもページの移動が手作業で大変だったりするシステム側の問題がある
      • 後述のようにページへのパーマリンクを階層構造とは切り離しておけばパーマリンクは死なないし、REST APIなどでページを移動できるようにしておけば階層構造変更もそれほど高コストではなくなる1

タグづけ機能を追加する

タグ付けについては僕も階層構造と同時に実装するのは微妙だと思う。タグも階層構造もどちらも記事の分類目的なのだからどちらかにするか、あるいはタグ自体に階層構造をもたせるのがよいかもしれない( lang/javasystem-alpha/post-mortem などのイメージ)

Symbolic Linkのようなリンクを付加する

おそらくページを階層構造上の2箇所以上へ擬似的に置きたいという意図だと思うが、いっそhard linkにして普通に2箇所におけるようにすれば良いと思う。パーマリンクを階層構造と無関係にすれば実現は難しくない。

しかし既にある階層同士の参照を壊すわけにはいかないので、階層構造は維持される

ここはコンテキストが省略されすぎていてちょっとわからなかった

うまくいく場合

 誰もが納得する簡単な階層構造があるときは大丈夫かも
  日付
  音楽データ
   アーティスト/アルバム/曲名
 最初に階層構造を決めないとうまくいかない
  構造が綺麗に決まっていると、新参者でもデータを追加しやすい

この辺でこれを書いた人はそのページのカテゴライズ・階層構造上の位置が書いた瞬間に絶対的に決まるイメージを持っていることに気づく。それは確かにしんどい構造なので継続的に階層構造を保守していくイメージを持てばいいんじゃないかなと思う。

うまくいかない理由

 複数の属性をもつものをどこに置けば良いかわからない
  aka [こうもり問題]
  こうもりは動物か鳥か分類し辛い
  特に複数人で書いているwikiでは判断が分かれて、ケンカの元になる
 階層的に分類するのは疲れる
 階層構造の変更が大変
  最初に決めた階層は大抵見通しが甘いのに

複数の属性を持つケースは階層構造上の複数の位置への配置を許容してしまえばいい(前述のハードリンク)。 階層構造の変更が大変な点はサービス・システム側で補助してやればいい(前述)。

何故階層脳になるか

ここに関してはおまそう要素が強すぎるので省略。

階層脳脱出するには

 Webと似たようなものだと言えばどうか
  無階層でも検索できれば良いと思う
  「Yahoo JPのトップページ使わないでしょ?」
 Gyazz的なものの有用さをじわじわ浸透させる
 複数人でのwiki運用では階層分類に困るものが頻出する
  例
   [カレーうどん]
   プロダクトAとプロダクトBの連携機能についてのユーザーサポートページ
    どの階層に入れる?ユーザーサポート or A or B
  厳格なルールを決めないと、分類できない
   そのルールは全員が覚えられない
   間違った場所に保存すると怒られるから、wikiを書けなくなる
  ガチガチの運用ルールで縛らないと普通のwikiは使えない

普通にページを階層構造上の2箇所以上へおけば良さそう。 またその情報共有サービスの全記事に対して同一のルールを強制するのではなく、その中を縦に区切ってそれぞれの中で分割統治する方式はどうか(イメージとしては部署ごとにその中が整理されている感じ)


書いていて自分のイメージするタグ/階層構造の仕組みがだいぶイメージできてきたので後日文書化する。


  1. 過去これを達成するためにredmine wikiの階層構造を簡単に整理するためこういうものを作ったりしていたのを思い出した bigwheel/rmwikifs

「未来のチームの作り方」感想

Amazon.co.jp: 「未来のチーム」の作り方 (SPA!BOOKS) eBook: 藤村 能光: Kindleストア

科学的な裏付けなどがあるわけではなく、そのままの形で汎化はできない。 1サンプルとして認識すればヒントはたくさんある。

まず以前読んだ本でもそうだったが、オンサイトのメンバーとリモートの人間で情報格差を作らないことが一つ重要な点に思える。

P180 仕組み9のミーティングをチャット込みでやる手法はよいかも。 書いてあるとおりメリットも多そうだし、これならリモートでやりたい人も参加しやすい。

【WIP】「SRE サイトリライアビリティエンジニアリング」まとめ&感想

第Ⅰ部 イントロダクション

1.3.1 エンジニアリングへの継続的な注力の保証

SREの運用業務のタイプと時間を(何らかの方法で)計測し、運用業務が50%を上回らないようにする。 50%を超えた場合は開発チームへ差し戻す。 これらは運用の自動化による効率化を即し、継続するためのルールである。

1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する

100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っている。

99.99%の可用性を99.999%にするには10倍のコストでは済まない。 現実的ではない。また効果もない。

エラーバジェット 1から信頼性の目標を引いた残りの数。

1.3.3 モニタリング

チケットという分類。これは入門監視にもなかった概念で、導入してもいいかも。

(1) Koji TanakaさんはTwitterを使っています: 「SRE本「ページャー」って何かと思ったら、いわゆるポケベルのことらしい。page=呼び出しってことであってるかな?」 / Twitter

2.2.1 マシン群の管理

BorgがMapreduceのようなバッチジョブもWebサーバーのようなデーモンも実行するのは意外。 これはKubernetesに通じるものがある。デーモンも不意に死ぬから扱い一緒ってことか?

2.2.2 ストレージ

Cloud SpannerをBorg使ってどうやって実現しているんだと思ったけどなるほど実際kubernetesでもできるし 分散ストレージ上でもRDSは実装できるんだな。僕もよくよく頭が固い。

Paxosって元同僚が大学で研究していたと言っていたような。

2.5 Googleの開発環境

モノレポ戦略に関する言及。これ現実的なのかなあ。 うちでの導入を考えてもいいかも。

第Ⅱ部 原則

3 リスクの受容

なぜ信頼性100%、つまり可用性100%を目指さないのか。 一言で表すと信頼性がある一定を超えるとサービスおよびユーザーにマイナスになるため。 以下理由

  1. 一定以上の信頼性(例えば99.99%→99.999%)はコストが10倍では済まない
  2. 新機能や機能改善の速度が低下し、ひいてはサービスの有用性やユーザー利益を減ずる
  3. 一定以上の信頼性の違いはユーザーにはわからない(99.99%は月5分、99.999%は30秒だが殆どの場合ユーザー体験に違いはない)

上記は最終的にユーザーへ提供されるサービス・サイトのイメージ。

すぐにやらなくてよいかなと思ったことリスト

以下では比較的SREの人数が少ない組織での話。 サービスはスマニュ爆撃などを受けず、アクセス数がそれほど激しくない(つまり負荷がそもそも高くなく負荷の急変動もない)ようなサービスを想定。

今の手数的にやらないことを列挙しないと全てをやろうとして潰れる。 優先度の低いことをココに列挙してまずはそれ以外のことに注力する。

  • キャパシティプランニング(需要予測と負荷試験)
    • 扱っているサービスが現実的に急な高負荷が発生しにくいため、気づいてからスケールアウトで十分間に合う
  • セキュリティ
    • ファイアウォール、認証など当たり前ラインのものは入れる。terraformへ1行書けば済むようなこともやる
    • 一方でvuls、ニアリアルタイムでのライブラリ・フレームワークバージョンアップ、S3暗号化やKMSの複雑な活用などコストとリスクがROI的に見合わないものは優先度を下げる
  • 効率とパフォーマンス
    • html, jsなどフロント技術はおいておいて、現状バックエンドはアクセス数がそんなであることもあり最適化の必要性があまりない。いざとなれば一旦スケールアウトする選択肢もあるので優先度を下げる。
  • DX
    • エンジニアの快適さは求めない。ただしサービス改善にそれが有益である場合を除く
  • レビュー・スクラム型の結合度の高いチーム・モブプロ・ペアプロ
    • 軽視しているわけではないが、そもそも人数の少ないチームでは上記が回らない