こんにちは！私の名前はAlexeySkorobogatyです。2015年、私は開発者としてLamodaに入社しました。現在、私はeコマースプラットフォームのシステムアーキテクトであり、COREチームのテクニカルリードでもあります。この記事では、この5年間に得た洞察を、ストーリー、ミーム、文学へのリンクとともに、持ち帰り形式で共有したいと思います。







記事の下のコメントで、質問、意見、反論などの議論ができれば幸いです。

知られている

Lamodaでは、注文処理システムのサポートと開発に取り組んでいるチームに参加しました。明確なことは何もありませんが、ひどく興味深いものです。



以前働いていた小さいながらも野心的なウェブスタジオの後、私は大企業の真剣さの感覚に感銘を受けました。調整された開発プロセスは、完全に洗練されたメカニズムのように見えました。このような複雑で重要なシステムには、リーダーとチームメンバーによる厳格でありながら指導的なコードレビューが不可欠です。私にとって、ポイントタスクは飛んで、文字通り1つか2つのファイルに影響を与えました。コードベースとシステムの動作のほとんどは、戦争の霧によって私から隠されていました。



約1か月後、作業システムに実際の変更を加えることに関連する最初のタスクの1つを完了しました。その本質は、クライアントへの資金の返還に関するレポートに1つのフィールドを追加することに要約されます。コードレビュー、ユニットテスト、リリースをテストするQAエンジニア-すべてが正常に見えました。システムが大きくて複雑だったので、規則に従って週に2回リリースされ、木曜日に私の仕事は本番環境に移りました。ほとんどの日、リリースエンジニアはコードの作成とロールアウトに忙しく、その後、グラフ、エラー、キュー、ログなど、問題を示す可能性のあるすべてのタブを強制的に切り替えました。しかし、すべてが素晴らしかった。コードはマスターブランチにマージされ、他のタスクを処理するために分散されました。



ログと監視の無音は、ひどいバグを隠します。データベースクエリが誤った数の行を返しました。返される総額は実際の数倍でした...しかし、これについては月曜日にしかわかりませんでした。翌朝オフィスのエレベーターに乗ったとき、テックリードが私をどれほど疲れて非難したかを今でも覚えています。彼は午前3時までバグを見つけ、リリースの修正を準備しました。そして、会社は私の過ちからいくらかの影響を受けました。これは私の最初の重大なバグでしたが、最後からはほど遠いものでした。人々は間違いを犯します、そして彼らはいつもそれをします。



要点＃1：ビジネスプロセスとデータが最初になります。システムが動作するデータに注意することが重要です。変更を加える前に、何を扱っているかを判断してください。調整が行われる状況を理解します。レベルより上のコンテキストの観点から、解決されている問題を常に考慮してください。言い換えれば、ビジネスプロセスの観点から何が起こっているのか、影響を受けるモデルの消費者は誰かを明確に理解してください。アプリケーションの構造には、必要な数の抽象化レイヤーと、抽象化自体のさまざまな程度の品質を含めることができますが、モデルまたはビジネスプロセス全体が壊れている場合、これはまったく意味がありません。



私は同じチームで働き続け、経験を積み、6か月後、チームのスタンドアップで、注文処理システムがどのように機能するかを一般的に理解しているというフレーズを投げました。



もちろん私は間違っていました。



大規模なシステムの複雑さを過小評価してはなりません。アメリカの政治家ドナルド・ラムスフェルドはこれについて非常によく言った：

...私たちが知っているように、有名なものがあります。私たちが知っていること、私たちが知っていることがあります。また、既知の未知数があることも知っています。つまり、私たちが知らないことがいくつかあることを私たちは知っています。しかし、未知の未知のものもあります-私たちが知らないもの、私たちがそれらを知らないもの。そして、私たちの国や他の自由な国の歴史を見ると、最後のカテゴリーは通常難しいです。

要点2：複雑なシステムを使用する場合、システムについて私たちが知っていること、知らないこと、そしてそれらの動作が推測すらしていないことを理解することが重要です。そして、これは「可観測性に向けた監視」の傾向をツール化して追跡することだけでなく、設計における依存関係の管理とリスク評価についても同様です。たとえば、重要なシステムにクールなトレンドデータベースを使用することを決定する前に、このサイトに固執することを強くお勧めしますboringtechnology.club

すべてが壊れています

注文処理システムを2年間使用した後、アプリケーションの約80％を自信を持って知っていると言えます。つまり、システムの各モジュールについて、それがどのように機能するかを理解しており、変更を加えることができます。どのビジネスプロセスが特定のモデルに反映されているか、それらがどのように相互接続され、相互に影響し合っているかを知っています。隣のチームが設計した決済処理システムとの統合を行いました。統合に加えて、以前の支払いがシステムの一部であったため、古いコードのレガシーを取り除く必要がありました。このタスクは、大きなモジュールの最後で最も野心的なリファクタリングでした。すべてがとてもスムーズに進んだので、面白くもありませんでした。



同時に、開発者としての私の中で対立が生じていました。事業全体の運営に欠かせない注文処理システムがなぜこんなに壊れやすいのか、正直わかりませんでした。隣接する大規模システムも同様に脆弱でした。 2年間の作業で得たすべての経験から、複雑なシステムからのある種の信頼性は、標準的なテストケースを実行する場合にのみ期待できるように思われました。そして、ビジネスが要求する変更を加えようとすると、不幸な開発者の最初の抜本的な操作で事態は崩壊します。



これらすべてを振り返って、私は「すべてが壊れている」という記事に出くわしました。この記事では、著者が同じ問題について書いていますが、さらに大規模です（また、ほぼ同じですが、異なる角度から-ソフトウェアの劣化）。自分の内面の感情を外部から確認することに興奮するたびに、そのとき、記事を読んだ後、漠然とした不満がどのように鮮やかで明白な洞察に変わったかをようやく感じました。

それはとても複雑なので、ソフトウェアはとても悪いです。

私たちの仕事の例として遠くまで行く必要はありませんでした。ちょうどその瞬間、ポールを2つ追加するだけで、しばらくの間、注文の作成を完全に中断しました。



私たちの大きくて重要なシステムは、私たちの頭に収まらないのでとても悪いです！そして、システム内にロックされているすべてのビジネスプロセスは、マネージャーやアナリストの頭に収まらない-そして一般的に、すべてがどのように連携するかを理解するような人はいない。



要点3：システムを設計するときは、認知的負荷を考慮することが重要です。これは、技術ソリューションの複雑さ、および対象領域のモデルとプロセスで構成されています。適切に設計されたシステムは、対象領域に高い認知的負荷がかかり、技術的解決策が少ない。理想的には、単一のシステムには、1人が処理できる認知的負荷が必要です。



さて、問題は明らかです。しかし、過度に複雑で、したがって悪いシステムを書き直して、それを単純化する機会があると仮定します。他に何に注意を払う必要がありますか？サイバネティクスには、Conant-Ashbyの定理



があります。システムの優れたレギュレーターには、そのシステムのモデルが必要です。優れたレギュレーター



この定理の意味は、あるオブジェクトを制御したい場合、このオブジェクトの優れた（正確で理解しやすい）モデルが必要であるということです。また、オブジェクトが複雑であるか、オブジェクトに関する情報が少ないほど、オブジェクトの適切なモデルを取得することが難しくなります。これは、管理に悪影響を及ぼします。



私たちのすべてのサービスがモデルであることに異議を唱える人はほとんどいないと思います。しかし、私たちは何をモデル化していますか？状態だけでなく動作もモデル化するために、ビジネスプロセスに注意を払うことが非常に重要です。



2017年の終わりに、私は新しいCOREチームに異動しました。このチームは、モノリシックシステムの分解のためのIT戦略のタスクを実行するために特別に結成されました。私たちの主な目標は、その非常に大きくて壊れやすい注文処理システムを削減することでした（ボイスオーバー：サムライは、このパスに始まりがあることをまだ知りませんでしたが、終わりはありません！）。

それは私にとって新しい経験でした。まったく異なる原則と考え方を持つチーム。決定は迅速に行われ、実験と間違いを犯す権利がありました。バランスは完璧になりました。影響が最小限の場所でロールバックを試みましたが、重要な瞬間について各ステップを詳細に規定しました。



別の言語で注文を最初から作成するための新しいサービスを作成しました（php開発者であるため、golangに切り替えました）。最初の結果を評価し、書き直しました。シンプルさと信頼性に重​​点が置かれました。彼らはデータモデルを中心に置き、アーキテクチャ全体を構築しました。その結果、信頼性と回復力のあるサービスが実現します。実験的なメカニズムを使用して、問題なく動作させることができました。時間の経過とともに、構築されたシステムはその価値を何度も示してきました。







要点＃4：すべてのモデルが間違っていますが、いくつかは便利です。状態のモデリングは、正しく安定したシステムを構築するのに十分ではありません。行動を調べる必要があります：通信パターン、イベントのストリーム、これまたはそのデータの責任者。データ間の関係を探し、これらの関係の理由に注意を払う必要があります。

それはすべてダムダムダダダムダムについてです

私の大学では、数学分析のコースがあり、それは准教授と博士によって教えられました。エレナニコラエフナ。彼女は非常に厳格でしたが、公平でした。時々テストで問題に遭遇しました。その解決のために、講義を少し「ひねる」必要がありました-資料を理解するための独立した一歩を踏み出すために。ちなみに、2回目の合格となった最終試験では、柔軟性を示し、直感で問題を「良い」と解決しなければなりませんでした。これがE.N. 彼女は私たちにコース全体を教えてくれました、そして私が10年後にそれを使っています：

何をすべきかわからないときは、知っていることをしてください。

だから私はマタンをよく知っていることを誇りに思いました。 E.N.の基準によると素材を知るだけでは十分ではありませんが、何か新しいものを合成できるように、それを理解することも重要です。



要点＃5：遠くに行くほど、より多くの責任を負わなければならず、より多くの決定を下さなければなりません。ある瞬間、絶対的な自信はカテゴリーとして消えますが、代わりに一歩を踏み出す勇気に続いてバランスの芸術がやって来ます。



あなたの周りに、既存の不確実性を取り除くことができる適切な人がいない時が来ます。あなたは自分でリスクを評価し、自分自身に責任を負わなければなりません。不確実性に直面して決定を下します。



2018年の後半、私たちのチームはギフト券プロジェクトを主導しました。当初、私は処理とその周辺の開発を担当していました。その後、年末までに、プロジェクト全体の技術的リーダーシップが、チームの一部が去った後の力のバランスを回復するタスクとともに私に引き継がれました。



頭の中に存在するルールと開発者の世界秩序は継ぎ目で破裂し、ついに崩壊しました。大規模で複雑なプロジェクトの責任は、コンセプトと虹のある開発世界についての理想的なアイデアを私から打ちのめしました。制限の残酷な世界と十分な解決策には、私が従ったすべてのアプローチとルールの理解と改訂が必要でした。







要点＃6：詐欺師症候群。露出した場合はどうなりますか？もちろん、何もしなければ露出します。あなたが何か重要なことをした場合、しばらくするとあなたはあなたを暴露する人がいないことに気づきます。

発散と収束

私の「開発者の道」の年代学によれば、個人的な政策のプロジェクトについての技術的な観点から興味深い話があるはずです。このプロジェクトでは、リアルタイムのデータ処理を実装し、「オンザフライ」でシステムアーキテクチャの原則を変更し、イベントドリブンアーキテクチャに移行しました。しかし、これについては、Highload '19カンファレンスとは別のレポート（およびここHabréに関する記事）がすでにあります。したがって、私はむしろ、あまり管理ではなく、技術の「重要事項」についてお話ししたいと思います。



開発者がシニアの地位に成長したとき、それは「責任を負い、自律的に決定を下す方法を知っている」と読まれるべきです。次の古典的なステップはチームリーダーです。チームリーダーとは、主にチームの責任者です。人と開発プロセスのために。顧客は開発者のところに来るのではなく、チームリーダーのところに来て、チームリーダーにも義務を求めます。



それは逆説的なことであることが判明しました-開発者がエンジニアとして独立して働くように成熟するとすぐに、彼は管理と呼ばれる嵐に投げ込まれます。

いいえ、おそらく誰かにとって、この道は非常に快適に思えます。コンピュータシステムの相互作用のための非常に明確なアルゴリズムとプロトコルから人々のグループの調整への移行は論理的に見えます。しかし、プロフィールチャットやチームリーダーのための会議での会話のほとんどが「痛み」の概念を中心に展開しているのは当然のことのように思えます。



チームリーダーの苦痛は何ですか？エンジニアが管理を担当しているからではないですか？！いいえ、なぜこれが発生するのかは理解できます。技術管理の学校はありません。ITエンジニアは、管理などの「単純な」ことも含め、すべてを理解できるスーパーマンであると想定されています。



しかし、私は別の方向に進むことに決め、次のキャリアステップとしてテックリードのポジションを選びました。アーキテクトとして、私は開発チームと協力し

ていますが、1年前に私自身がマネージャーに言ったことをみんなから聞いています。なぜ、要件がそれほど開発されていないのですか？クラッチソリューション！なんと2週間？ここで一ヶ月働きます。



しかし、えへへい、今はそのような問題を解決することが私の仕事です。しかし、自分の考えをコストと利益のパラダイムに変換するとすぐに、これらすべての問題を解決することはできないことに気づきます。



要点＃7：オープニング！マネージャーは問題解決に対処しません;彼らは雑然と管理します。



テクニカルリーダーとしての私の仕事は、開発チームの不確実性を取り除くことです。要件が解決されていませんか？クラッチソリューション？アーキテクチャは提供しませんか？これらはすべて、システムの脆弱性と発散の兆候です。



注文作成サービスのタスク設定が次のようになっているとします

。XフィールドとYフィールドを追加する必要があります。Xが1



の場合、出力のY 'フィールドの値がZ値と等しい必要があります。問題は要件のステートメントそのものにあります。ここでの間違いは、達成したいシステムの状態が完全に不明確であるということです。ステートメントで完全に定義されたステップは、実装および操作中に不確実性をもたらします。

このようなタスクをいくつか実行すると、注文作成サービスはかなり脆弱な状態になります。たとえば、いくつかのフィールドを追加してすべてが壊れた場合などです。



目的：システムの状態の収束、タスクのステートメントの一貫性、および安定性を達成するための不確実性の低減を確実にすること。

表現の線に取り組んでいる人々は、線の向こうにあるもののモデルを絶えず構築し、更新しています。これらの活動は、インターネットシステムの回復力にとって重要であり、適応能力の主要な源です。境界線より上、境界線より下

建築家は、社会技術システムの統一性を理解する必要があります。提示線より上のプロセスを調整して、提示線より下のシステムが正確性、安定性、および適応性の制約を満たすことができるようにします。







要点＃8：ルールが機能しなくなった場合、おめでとうございます。現在のモデルが機能しなくなる境界条件に到達しました。アイデアを修正し、現在の制約を満たし、適切なプロセスとルールを構築できる新しいモデルを選択するときが来ました。

ソフトはシンプル、人はハード！

いいえ、違います。これは、建築に関する1冊の本に書かれたものです。そして、私が遠くに行くほど、この本を繰り返すことが多くなるように感じます。



技術的な概念、アルゴリズム、および標準は明確です。それを理解し、一貫して理解する必要があります。私はエンジニアの仕事を軽視しようとはしていません-分散システムのアルゴリズムは、そのようなシステムを日常的に構築しないと非常に複雑になります。しかし、多くの場合、作業の過程で遭遇する主な問題は、特定のサービスがドメインに対してそのようなレベルの抽象化を必要とする理由を理解する必要がある場合に発生します。そして、サービスを書いた人が周りにいないという事実によって、問題はしばしば悪化します。



実装が簡単なアルゴリズムは、数学的に正確なアルゴリズムよりも成功します。 Paxosは数学的に正確ですが、実装が簡単なRaftプロトコルの説明によってのみ、コンセンサスアルゴリズムの実用的なアプリケーションが開発されました。

ゴラン語は制限が多すぎると批判されています。しかし、Docker、Kubernetes、および他の多くの分散システムが作成されているのはその上です。適切に設計された制約システムは、システムを成功させるための基盤として機能します。



テクノロジーが人的要因を考慮する必要がなければ、すべてがはるかに簡単になります。しかし、彼らはしなければなりません。 ITのシステムは、その構築と保守に複数の人が関与するため、人的要因を考慮に入れる必要があります。



そしてここで、テクノロジーはソフトウェアと人の交差点に出現し、カオスを構造化し、複雑な相互作用を記述するように設計されています。ドメインドリブンデザイン、マイクロサービス、アジャイル-これらはすべて、相互作用の原則とルールを説明する制約を作成します。作業方法が明確な構造が表示されます。しかし、そのような技術の出現で常に良くなるとは限りません。かなり頻繁にそれは逆になります-お金が買えないもの。



要点＃9：プログラムは単純である可能性があります。これを行うには、エンジニアリング文化の形成に力を加える必要があります。最終的にサービスのパフォーマンスを決定するのは彼女です。

リーディングリスト

Books



The Manager's Path：成長と変化をナビゲートする技術リーダーのためのガイド、Camille Fournier-リンク



TheElegant Puzzle：Systems of Engineering Management、Will Larson- Link



Team Topologies：Organizing Business and Technology Teams for Fast Flow、Manuel Pais and Matthew Skelton-リンクは



-ソフトウェア、ジュバル・ロウィ立ち直りリンク



A入門、Donella：システムにおける思考メドウズ-参照



記事



-メンタルモデル、ストリート一般Fernamリンク



我々は複雑に好む理由：複雑バイアスをシンプル。ファーナムストリート-リンク



お金が買えないもの、LessWrong-リンクが



異常に真実志向になり、LessWrong-リンク



プログラミングの法則と現実：私たちは自分たちが知っていると思うことを知っていますか？-リンク



特効薬エッセンスとソフトウェア工学の事故-リンク



-トラブルシューティングのアートリンク



Antifragileソフトウェアに脆弱から-リンク



コンピュータが理解できる-リンク



Tuckmanが間違っていました！（チームについて） -参照



ほとんどすべてで失敗し、まだ方法は大きな勝利-リンク



一般性の前にシンプルに、再利用する前に、使用-リンク

シンプルさが、してください-ソフトウェアのためのA・マニフェストの開発-リンク



ソフトウェア設計は人間関係です-リンク