- Chris KrychoはLinkedInで約5年間、デスクトップWebアプリのフロントエンドインフラと開発者体験を担当し、大規模コードベースを安全に変えることと迅速なプロダクト実行要求の衝突を経験した
- 入社当時約200万行のJavaScriptだったLinkedInデスクトップアプリは、その後約320万行のモノレポへと成長し、移行は自動化とプロダクトチームの負担最小化なしには現実的に難しかった
- EmberのモダナイゼーションとTypeScript導入はエラー削減と開発品質改善を狙ったもので、TypeScript移行によってアプリケーションログのエラー量を少なくとも25%減らせるという分析が社内説得に使われた
- EmberからReactへ移る計画では、Chrisのチームによる3〜5年の段階的自動化戦略と、より速いプロダクト実験のため既存方式を大きく再設計しようとするアプローチが衝突した
- 大規模障害への対応過程で、アラート、可観測性、レジリエンス、コードレビューの限界が明らかになり、Chrisは速度を最優先に置く組織の方向性が自分の価値観と合わないとして去った
5年間担当した仕事とコードベースの規模
- Chris Krychoは2019年1月末にLinkedInに加わり、約5年間勤務した
- 担当領域はサーバーインフラではなく、LinkedInデスクトップWebアプリのフロントエンドインフラと開発者体験の改善だった
- LinkedIn.comのモバイル以外のブラウザ体験を担うデスクトップアプリで、大規模なJavaScriptモダナイゼーションプロジェクトを率いた
- 前職のアプリは約15万行規模だったが、LinkedInのフロントエンドは入社当時約200万行のコードだった
- 同じアプリに四半期ごとに150〜200人のエンジニアがコミットし、数十のチームが1つの製品を継続的にデプロイする構造だった
- 入社当時、リモートのエンジニアは全体の数千人のうち100人未満で、ChrisはColoradoからリモートで働く珍しい例だった
200万行のコードをどう移行するか
- 初期の大きな仕事の1つは、EmberベースのコードにJavaScriptの現代的なclass構文を導入することだった
- 既存のEmberクラスとネイティブJavaScriptクラスが継承チェーンで混在する問題があり、社内ではこれを「Zebra Striping」と呼んでいた
- この規模の移行は可能な限り自動化される必要があった
- 200万行を手作業で直すには数か月以上かかりうる
- プロダクトチームに機能開発を止めて新構文導入だけを求めるのは難しい
- LinkedInには複数チームを横断する**水平イニシアチブ(horizontal initiatives)**のプロセスがあり、プロダクトチームの参加を10%以下に抑えようとする運用原則があった
- Chrisのチームは、プロダクトチームが直接codemodを実行する方式より、インフラチームが自動化でPRを作り、プロダクトチームはレビューとスモークテストを担当する方式のほうが受け入れられやすいと判断した
- Ember関連の作業は全体で18か月かかり、大半は6か月以内に進んだが、一部チームの遅れで長い尾を引いた
TypeScript導入を説得したエラー削減の論理
- Emberのモダナイゼーション後、Chrisのチームはフロントエンドで発生する大量のJavaScriptエラーを次の対象にした
- LinkedInはエラーログの規模が大きく、外部サービスではなく社内のロギングインフラを使っていた
- LinkedInは前年に会員数10億人を超え、Chrisが去る時点でモノレポは約320万行規模だった
- ChrisのチームはTypeScriptで捕捉できるエラーのカテゴリを別途分析した
- 一部のエラーはTypeScriptでも捕まえられないが、移行全体を終えれば1日あたり数百万件規模のJavaScriptエラーのうち、アプリケーションログ量を少なくとも25%減らせると見ていた
- Chrisが書いたTypeScript移行文書は、エンジニアとマネージャーの間で繰り返し共有された
- 解決しようとする問題
- 期待できる利点
- 採用競争力での比較
- 他の優先順位と比べる判断材料が含まれていた
- その後Chrisは、厄介なTypeScriptの型問題を助ける社内エキスパートの役割を担うようになった
EmberからReactへ: 段階的移行と全面的再構想
- LinkedInは世界で最も大きいEmberJSユーザーだったが、Chrisの仕事は最終的にEmberからReactへ移る計画を立てる方向に変わった
- 上級リーダーたちは、LinkedInの移行コストが高すぎて、プロダクトの速度を落としていると見ていた
- Chrisのチームの計画は3〜5年の段階的自動化戦略だった
- プロダクトチームがほとんど止まらないよう自動化を強化する
- ビルドパイプライン、データ層、ルーティング層、リアクティビティシステム、ビュー層を順に分離して移行する
- 最後にEmberのレンダリング・リアクティビティシステムをReact側に置き換える流れだった
- 別のチームは速度問題をより直接的に狙った
- アイデアからA/Bテストまでにかかる時間を数か月から数週間レベルに縮めるのが目標だった
- デスクトップWeb、モバイルWeb、iOS、Androidの異なるスタックと長いサイクルタイムを問題視していた
- Chrisはそのチームのアプローチを「finger guns mode」に近い態度として受け止めた
- 数十人を支えていた経験を数百人のエンジニア支援へ拡張する際に生じる問題を十分に扱っていないと感じた
- 質問に対して「問題にならないだろう」という反応が多かったと見ていた
- Chrisのチームの3〜5年計画はリーダーシップにあまり好意的に受け取られなかった
- 計画自体が長く、面白みに欠けた
- チームも「最もましではあるが理想的ではない選択肢」のように提案していたため、説得力が弱かった
障害対応で露呈したレジリエンスの問題
- Chrisがクリスマス休暇から戻った後、LinkedIn.comのページが一部ユーザーに対して最大約20分見えなくなる問題が発生した
- 問題は、クライアントコードをNode.jsで実行してバックエンドデータを集めて素早く渡すプリレンダリングサービスに関連していた
- サービスにはメモリリークがあり、コンテナがメモリ上限を超えると再起動される構造だった
- 障害を拡大させた要因がいくつも重なった
- メモリkillに対するアラートが十分でなかった
- 同時に再起動できるコンテナ数の設定がYAMLファイルのキーとして存在していた
- その値は型としては取りうる値だったが、このシステムでは誤った値だった
- 設定値は事実上、稼働中サービス全体の数に近かった
- デプロイ停止が長い週末のように長引くと、サービス群が似たタイミングでメモリを使い果たし、一斉に再起動してユーザーリクエストを処理できなくなった
- 一部サーバーが落ちると残りのサーバー負荷が高まり、それらのサーバーのメモリ使用量もさらに速く増えて、データセンター単位でサーバーが落ちる状況が生じた
- 同時に、fleetのCPUとメモリ使用量を減らす**リソース最適化(rightsizing)**作業が進行しており、余裕が減っている状態だった
- Chrisと他のエンジニアたちは、より良いアラート、可観測性、レジリエンスが必要だと見ていた
- Nodeサーバー1台が暴走状態になっても、ホストプロセスまで落としてはならない
- Nodeプロセスだけを終了してアラートを出し、その後再起動するほうが安全だ
- サービスが落ちたらクライアント側fetchへ切り替える代替経路も検討した
コードレビューだけでは防げないという衝突
- 障害対応会議は週に複数回行われ、進捗共有と役員への報告の性格を持っていた
- 別チームのマネージャーが障害対応を担って追加人員を投入し、Chrisは自分と既存チームの答えを信頼しない流れとして受け止めた
- その過程で、あるシニアエンジニアが「なぜコードレビューでこれを防げないのか？」と尋ねた
- Chrisはコードレビューだけでは同じことの再発を防げないと考えていた
- 人はミスをする
- ジュニアエンジニアが非常にシニアなSREのPRで設定値が妥当か疑うのは難しい
- システムはシニアエンジニアの最高の日だけでなく、ジュニアエンジニアの悪い日にも安全に動作すべきだ
- Chrisにとってソフトウェアエンジニアリングとは、プロダクト成果を出すエンジニアを支えるシステム設計まで含んでいた
- 技術的障害と組織的コミュニケーションは切り離せず、Charity Majorsの言葉どおり、高位レベルでは純粋に社会的な問題だけ、あるいは純粋に技術的な問題だけというものは存在しない
リーダーシップ、リモート文化、価値観の衝突
- Chrisは、自分のチームとアプローチが別チームの提案に押し切られたと見ていた
- 別チームの計画はデスクトップとモバイルアプリの両方を再考する方向へ広がり、LinkedInのプロダクト構築のやり方全体を見直す性格を持つようになった
- Chrisはその提案をより良くしたかったが、懸念や質問が十分に受け止められていないと感じた
- あるマネージャーから「君は理想主義的すぎるし、損益を十分に気にしておらず、価値観を変える必要がある」と言われたという
- Chrisはリモート勤務が関係構築に影響したと見ていた
- LinkedInは対面文化が強く、多くの人がカフェテリアや廊下で自然に関係を築いていた
- 上級エンジニアや役員との反復的な物理的接触が、対立状況で差を生みうると感じた
- Chrisは自分にも関係構築の弱さがあったと振り返っている
最終的に去った理由
- Chrisは、既存コードベースの多くの問題は速度を過大評価し、補助経路の問題を修正または除去しなかった結果だと見ていた
- 速度が最優先の価値になると、初期の速さは得られても時間が経つにつれて維持しにくいと判断した
- 彼は前職でバーンアウトを経験しており、ひどい偏頭痛、腹痛、運動不能、突然の涙、パニック発作を経験したという
- LinkedInで働き続ければ、毎日怒らないよう努力し続ける状態になると見ていた
- 巨大な組織の方向を小さなオール付きボートで変えようとする状況になぞらえ、自分が信じていない方式や仕事に何年も費やさないと決めた
- ChrisはLinkedInで300万行規模のアプリ、大企業でのTypeScript移行、大規模エンジニアリング問題を学んだが、自分の価値観に合う仕事を探すために去った
1件のコメント
Hacker News の意見
ポッドキャストで最も興味深かった箇所は、「理想主義的すぎる、損益に十分注意を払っていない、価値観を変えるべきだ」というフィードバックだったと思う。読む前からそういう印象を受けていたし、途中で何度も価値あるフィードバックを受けていたのに、意図的に無視したように聞こえる。
シニアスタッフエンジニアにとって難しいのは、「正しいこと」そのものではなく、正しい解決策に向けて組織全体のアラインメントを作り出すことだ。2019年に facebook.com を React で書き直す作業に参加していたので、この話は特に興味深く感じた。
コミュニケーションはある程度できていたが、LinkedInにいる間、その整合には大きく成功しなかった。一部は自分の責任であり、一部はLinkedInの責任でもある。
ただしこの場合、「理想主義的すぎる」という言葉は本当に「損益に直接貢献しないことは気にするな」という意味であり、それは骨の髄まで拒否する。損益は重要だが、ユーザー体験、開発者体験、そして私たちが何を作るのかに関する基本的な倫理も重要だ。
組織では、自分が正しいと信じることを全力で擁護し、別の誰かや合議体が同意するかどうかを決める。その結果を受け入れるか妥協するか、それとも去るかは自分が決めることで、キャリアの中でどちらも経験してきた。
有名なユニコーン企業に、とても頭が良く、合理的で親切なシニアスタッフエンジニアがいた。年間5,000万ドル規模で使っているフレームワークを v2 から v3 に上げようと推進していて、Python 2 から 3 への移行と比べればごく些細な変更だった。
調査の結果、基本的に10%の性能改善が期待できるにもかかわらず、経営陣は「バージョンアップに時間を無駄に」したがらなかった。結局そのエンジニアが1人で押し進め、1カ月も経たずにプレビュー版を作り、2カ月以内に大きな効果が出る作業の一部を移行して、自分の年俸の何倍ものコストを節約した。
初期の政治的コストとエンジニアリングコストが支払われると、誰もが移行したがるようになり、1年後にデプロイが完了した時点で、上層の管理体制は半分ほどが解雇や退職で入れ替わっていたが、そのエンジニアとマイグレーションは残っていた。時にはスタッフエンジニアが意固地なのではなく、狂った世界で唯一まともな人間であることもある。
そういう場にいたことがあり、関与しないこともできたが、常にそうできるわけではない。
最高のアイデアや計画がなくても、適切なコネ、適切なランチの場、適切な言葉で経営陣を説得する例を見てきた。
「君は理想主義的すぎて、損益に十分注意を払っていない」という言葉も、誰かを押しのけるためのレッテル貼りの表現かもしれない。特に、そのように自分と自分のアイデアを上層部に売り込んできた人ならなおさらだ。
個人的にはFacebookよりは小さいが、数百人のエンジニアと大きなコードベースを持つ組織で、Ruby、Rails、Postgres関連の大規模な変更とアップグレードを何度も経験してきた。Chrisが説明した方法論は非常に合理的で、自分が成功したと感じたやり方とも一致している。
リーダーシップの役割は、信頼と尊重があってこそ効果的だという点には同意する。もちろん、その信頼が有用であるためには、実際にも正しくなければならない。誤った方向への前進は、前進ではない。
LinkedInのコードベースを知らずに働いたこともありませんが、恐ろしいほど似た響きのコードベースや組織・政治構造は何度も見てきました。なので、たいていはフィンガーガン方式を支持します
フィンガーガン式の書き直しも、うまく実装できます。同じことをするクライアントが複数あるなら、そのうち1つを別プラットフォームの基盤にできますし、新しく始めるとしても、クリーンで速く簡潔にできます
成功の鍵は、ドメインエキスパートであり技術エキスパートでもある少数のベテランチームに新システムを任せることです。議論の余地はありますが、平凡な運用保守の問題も含め、すべての成功はここから来ると見ています。それ以外は速度を落とすだけです
ほとんどの技術系経営陣が繰り返す大きな問題は、次の大きなシステムを最も経験の浅い人たちに任せる点です。フィンガーガン側からの対称的なインタビューも聞いてみたいです
彼らがすでに効果を見た実証済みのものなので自然ではありますが、常に最善とは限りません。しかも、ベテランチームがプロジェクトを始めても最後まで残ることはまれで、結果や余波を引き受けなくてよいなら、意思決定はあまりにも簡単です
計画には、障害を扱うための現実的な選択肢が必要で、それは技術的な選択肢だけでなく、その仕事をする人の時間と能力まで含みます。たとえば複数のチームがサーバーを運用する計画なら、技術的には可能でも、チームに時間や能力がなければ現実的な選択肢ではありません
逆に、すべての障害を避けていく精緻な経路を計画するのもよくありません。到着するころには障害が動いているかもしれず、道の上にはまだ知らない障害があるかもしれないからです。1本の道だけを計画していたなら、そこで止まってしまいます
ただ、いま見ているのは複雑なアーキテクチャ論争を漫画のように要約したポッドキャストの説明なので、LinkedInで実際にどのストローマン論法が近かったのかは分かりません
取締役会がエンジニアリング全体に対し、今後どのプロジェクトでも誰も詳細を指示してはならないと言ったそうです
Chrisはいくつか不運な選択をしたように聞こえます。5年計画を提案し、出来事をリーダーシップではなく非難へと向け、問題を解決するよりも問題について多く語り、関係構築も足りなかったようです
Chrisに共感する一方で、この環境で成果を出す方法を知らなかったようにも見えます。それでも構いません。誰もが官僚主義的なもつれの中で働く方法を学ぶ必要があるわけではなく、スタートアップはその点でより単純です
大企業が時間とともに切れ味を失い、ある役員が会議室で、率直にものを言う副社長が一人もいないまま前年比-10%の損失に向き合うことになるのには理由があります
こういう状況にいると、心理的に方向感覚を失います。自分は正しい気がするが、本当に正しいのか。周りの人たちは本当にそこまで無能で、同僚から学ぶことに関心がないのか。
数年後に離れて振り返ると、その人たちは解雇されたか去っており、組織はいまだにXができず、その後加わったチームの機敏さと能力は実際に存在していました
一方では、傲慢さ、政治的無能さ、病的な実務文化に適応できないことなのかもしれません。他方では、それが正しい反応なのかもしれません
組織が病的な文化局面を通っているなら、才能があり慎重で情熱的な人たちがそれによっておかしくなっていくのは当然かもしれません。それでおかしくならない人たちは、生産性や成長に無関係か、さらに悪ければ純損失かもしれません
だからこうした環境は心理劇になります。状況は本当にここまで悪いのか、それとも自分が過敏に反応しているのか
しかし、経営陣が「われわれが依頼した移行であっても、プロダクトのイテレーション速度を一切落とすな」と言った状況で、持っていけると感じた唯一の計画でもありました
出来事を非難へと向けたという部分は、何を意味しているのかよく分かりません。むしろ逆をしようとしていて、メモリしきい値を下げた人や、YAMLに誤った値をタイプミスした人を責めませんでした。ただ、次の人がまた爆発させるまで根本原因を放置せず、実際に解決しようと主張しただけです
問題を解決するより話ばかりしていたという部分もよく分かりません。番組で自分が成し遂げたことを長々と自慢しなかっただけで、そこで解決した問題はかなりうまくやりました
関係構築不足は、エピソードでも話したように私の最も弱い部分でした。エンジニアたちとの関係は良かったのですが、特に上層の管理職と政治的信頼を築くことには大きく失敗しました
それでも、単にその環境で成果を出す方法を知らなかったからだけだとは見ていません。成功できるやり方は見えていましたが、自分が信じていないやり方で行動しないという選択もありました。私が尊敬するエンジニアの多くは、信じる仕事のためなら政治的なダンスを踊りますが、信じていない仕事のためにはそうしません
現在LinkedInで働いている。Chrisの役割とポッドキャストはEmberとフロントエンドWeb開発を扱っているようで、彼が言っていたコード行数とビルドは、おそらくLinkedInのモノリシックな代表的Webアプリである voyager-web の可能性が高い。
LinkedInには、数百万行のコードと長いビルドを抱えるシステムがほかにもある。中間層、オフラインデータスタック、メトリクスシステム、そしてKafkaKafkaKafkaのようなものだ。
残念ながら 17分ビルド はかなり良いほうだ。一時的なインフラ障害なしで17分なら非常に良い。
会社全体にテストという概念がほとんどなく、QAもない。エンジニアたちは昇進資料に入れるために半分生煮えのプロジェクトを押し込み、次へ進んでいく。
内部ツールを日常的に使いながら、あまりにも多くの問題を自分で解決しなければならず、仕事をしようとするエンジニアが事実上QAになる構造だった。
その代わりに、ビルドを速くする、あるいはビルドインフラをより速く安くする方向へ進むべきだ。
少なくとも私がいたチームではコード品質がかなり重視されており、文化も改善され続けていた。ただしvoyagerの作業を一度やったことがあるが、それは悪夢として記憶している。
大規模な書き直し は管理可能なコードベースでも危険で、残った残骸は最後まで消えないように思える。数年後に隅に押し込まれた設定ページを書き直すことで、誰が評価を得たいと思うだろうか。
こうした試みをあまりにも多く見てきたので、コードベースを書き直すためのフレームワークがあってもよさそうなものだが、ない。自動コード修正ツールは一貫性を要求するが、そうした一貫性を守れている場所はまれだ。コードパターンは時間とともにあまりにも大きく進化していて、年輪を見ているような感覚になる。
私たちは基本的にコードを箱に入れ、箱を並べ替え、どの配置がより効率的かを妥当に語っている。なのになぜ、もっと良い方法を見つけられないのだろうか？ 自動化はコードレベルでは機能するが、箱レベル では機能しない。
これは コンウェイの法則 が働いている事例だ。組織が変わっていないのだから、同じコードのスープをまた作る可能性が高い。
同じ船に乗ったことがある立場から言うと、前向きなエンジニアリング施策は、非常に高い位置にいるスポンサーを通じてトップダウンで降りてこなければならない。ボトムアップで組織を変えることはできず、コードベースを作るのは結局組織だからだ。
コンウェイの法則は変わらないが、必ずしも正式な組織図だけに依存するわけではない。適切なテックリードと有能なマネージャーの間に一時的なコミュニケーション構造を作れば対処できる。
ただし途中に技術的に弱い、あるいは自分の王国を築こうとするマネージャーが数人いるだけで全体は簡単に壊れるし、会社のライフサイクルによっては Pournelleの官僚制の鉄則 のために、すでに見込みがない可能性もある。
たとえば、開発者が全員ひどい場合に人気のあるフレームワークを与えるようなものだ。人の問題に向き合わないための言い訳であり、子どもたちに保育園を運営させるのを許すようなものだ。
卓越性を求めるなら、責任を問うこと、オーナーシップと報酬・責任を課すルールによって高い基準を設けるべきだ。複雑ではないが、上からの断固たる姿勢と衝突を恐れないことが必要だ。
ただしMicrosoftのような会社が何かを作ったあと、それを台無しにしないという希望をすべて失うことになるかもしれない。
LinkedInで12年を過ごした。悲しいことに、かつてのエンジニアリング組織とはほど遠い。Kevin Scott がエンジニアリングを率いていた時代は、比べると本当に良かった。
JavaScript が数百万行とは、それ自体が肥大化の化身だ
LinkedIn のようなものを作り直す、正確には「Facebook っぽい」機能のない自分の連絡先データベースを作ることを考えてきた
問題は、自分の連絡先をどうやって大量に移行してもらうかだ。肥大化とは別に、Microsoft LinkedIn の主な問題は連絡先情報をエクスポートさせてくれないことで、連絡先プラットフォームならこれは必須機能だ
https://queue.acm.org/detail.cfm?id=2567673
要約: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn は2010年初めに Node へ移行した
ただ、このスレッドの反応を見ると、その数字が間違っていたのかもしれないとも思う
LinkedIn ではやったことがないが、公開 Web サイトに載っているカンファレンス参加者リストをエクスポートするときに自分が使っている泥臭い小技だ。状況次第かもしれない
Chris Krycho が非難の応酬に向かわず、自分の苦労を率直に語るやり方が印象的だった。CoRecursive は、コードの背後にある複雑な文脈を扱うので、好きなポッドキャストの一つだ
ほとんどの場合つらいソフトリーダーシップの役割のように聞こえる。何かについて「責任」はあるが、組織の他の部分に対する権限はほとんど、あるいはまったくない立場だ
実際の技術リーダーシップがあるなら、その場を離れていたか、長く在籍していて「システムの専門家」だとしても、実際の問題とはもはや接点がなくなっている状態なのかもしれない。経験したことがあるし、二度と御免だ