「インフラ・プロセス・速さ – Spinach Forest」
ZUCKERBERG: We’ve changed our internal motto from "Move fast and break things" to "Move fast with stable infrastructure." Mark Zuckerberg on Facebook's Future, From Virtual Reality to Anonymity | WIRED Zuck 氏が "Move fast with stable infrastructure." と言ったのが 10 年前。 Feature Flags の必要性 アプリの社内ベータリリースを派手に壊した若者が retrospective を書いたというので眺めていると「単体テストのカバレッジが足りませんでした。テスト真面目に書きます。」と書いてあり、固まってしまった。いや、テスト書くのはいいんだけどさ・・・。 「フラグがあるといいんじゃない？」とコメントしたら若者の上司が出てきて「うちのチームでも会社全体でも、フラグの外側でバンバンコード書いてんじゃん？アンラッキーな事故だよ」という返事。ふたたび固まってしまった。 あんたそれ稼ぎ頭のアプリ相手に言ってごらん・・・。 インターネット動画部門のアプリチームで仕事をしていた頃、すべての変更はじっさいフラグの裏で行われていた。リファクタリングさえも、明らかに安全なものを除けばフラグの裏だった。毎週のように出ていくリリースで何かが壊れるとアラートがあがりチャットが開かれ、ばばばっと問題のフラグが特定され、壊れる挙動はサーバからのフラグデータ更新で無効化される。これは動画部門に限った話ではなく何億人もユーザがいる他のアプリたちでも同じだと思われる。同じインフラが使われているし。 そのむかし大企業で働き始めた頃「このプロジェクトは revert first だから、何かが壊れたら怪しい変更はバンバン revert するんだよ」と言われて感慨を受けた。フラグプッシュで問題を直すのはその先を行っている。バイナリを配り直さない。モバイルのようにバイナリの再配布が難しい環境ではフラグに圧倒的優位がある。 もちろんこれは、特にサーバ側の世界では特段珍しい話ではなく、アプリが使っているフラグの仕組みもそっちの世界から来たものである。Devops…
Webページ
コンテンツ文字数：0 文字
見出し数（H2/H3タグ）：0 個
閲覧数：11 件
2025-02-09 14:08:20
オリジナルページを開く
