CTO の能力が試されるのは、この役割を XNUMX 回目に実行するときだけであることが知られています。 なぜなら、会社で数年間働き、会社とともに進化し、同じ文化的背景の中で徐々により多くの責任を負うことは別のことだからです。 そして、レガシーな荷物や多くの問題をきちんと隠蔽されたまま、そのまま会社のテクニカルディレクターの職に就くのは全く別のことだ。

この意味で、彼が共有したレオン・ファイアの経験は、 DevOpsConf、必ずしもユニークではありませんが、彼の経験と、20年間にわたってなんとか挑戦してきたさまざまな役の数を掛け合わせたものは、非常に役に立ちます。 カットの下には、90 日間にわたる出来事の年表と、他人の身に起こったときは笑うには楽しいが、直接直面するとそれほど面白くない話がたくさんあります。

レオンは非常にカラフルなロシア語で話しますので、35 ～ 40 分の時間があれば、ビデオを見ることをお勧めします。 以下は時間を節約するためのテキスト版です。

レポートの最初のバージョンは、人々とプロセスの連携についてよく構造化された説明であり、有用な推奨事項が含まれていました。 しかし、途中で遭遇した驚きのすべてを彼女は伝えたわけではありません。 そこでフォーマットを変えて、新しい会社でびっくり箱のように目の前に現れた問題とその解決方法を時系列で提示しました。

XNUMXヶ月前

多くの良い物語と同様、この物語もアルコールから始まりました。 私たちは友人とバーに座っていましたが、IT 専門家の間では予想通り、誰もが自分たちの問題について泣いていました。 そのうちの 15 人は転職したばかりで、テクノロジー、人々、チームに関する問題について話していました。 話を聞けば聞くほど、彼は私を雇うべきだとますます感じました。なぜなら、これらは私が過去 XNUMX 年間解決してきた種類の問題だからです。 私は彼にそのことを伝え、翌日職場で会いました。 その会社はティーチング・ストラテジーズと呼ばれていました。

Teaching Strategies は、誕生から 40 歳までの幼児向けカリキュラムの市場リーダーです。 従来の「紙」企業はすでに創業 10 年、デジタル SaaS バージョンのプラットフォームは 2017 年が経過していますが、比較的最近になって、デジタル テクノロジーを企業標準に適応させるプロセスが始まりました。 「新しい」バージョンは XNUMX 年に発売され、古いバージョンとほぼ同じでしたが、動作が悪くなっていました。

最も興味深いのは、この会社のトラフィックは非常に予測可能であるということです。日ごと、年ごとに、いつ何人の人が来るかを非常に明確に予測できます。 たとえば、午後 13 時から 15 時までの間に、幼稚園の子供たちは全員就寝し、教師が情報を入力し始めます。 そして、週末にはほとんど誰も働かないため、これは週末を除いて毎日起こります。

少し先を見てみると、私は年間トラフィックが最も多い時期に仕事を始めたことに注目します。これにはさまざまな理由があって興味深いです。

わずか 2 年前に作られたように見えるこのプラットフォームには、2008 年からの ColdFusion と SQL Server という独特のスタックがありました。 ColdFusion は、ご存知ない方もいるかもしれませんが、おそらくご存知ないかもしれませんが、90 年代半ばに登場したエンタープライズ向け PHP であり、それ以来、私はその名前さえ聞いたことがありません。 Ruby、MySQL、PostgreSQL、Java、Go、Python もありました。 しかし、メインのモノリスは ColdFusion と SQL Server 上で実行されました。

問題

社員と仕事の内容や困ったことについて話せば話すほど、問題は技術的なものだけではないことがわかりました。 そうですね、テクノロジーは古いです - そして彼らはそれに取り組んでいませんでしたが、チームとプロセスに問題があり、会社はそれを理解し始めました。

従来、技術者は部屋の隅に座って、何らかの仕事をしていました。 しかし、ますます多くのビジネスがデジタル バージョンを利用し始めました。 そのため、私が働き始める前の昨年、取締役会、CTO、CPO、QA ディレクターといった新しいメンバーが会社に登場しました。 つまり、同社はテクノロジー分野への投資を開始した。

重い遺産の痕跡はシステムの中だけにあるわけではありません。 この会社には従来のプロセス、従来の人材、従来の文化がありました。 これらすべてを変更する必要がありました。 絶対に退屈しないだろうと思って、やってみることにしました。

XNUMX日前

新しい仕事を始める 4 日前に私はオフィスに到着し、最後の書類に記入し、チームに会ったところ、当時チームが問題に苦しんでいることがわかりました。 それは平均ページ読み込み時間が2秒、つまりXNUMX倍に跳ね上がったことです。

グラフから判断すると、何かが起こったのは明らかですが、何が起こったのかは明らかではありません。 問題はデータ センターのネットワーク遅延であることが判明しました。データ センターの 5 ミリ秒の遅延が、ユーザーにとっては 2 秒に変わりました。 なぜこれが起こったのかはわかりませんでしたが、いずれにしても、問題はデータセンターにあることが判明しました。

初日

XNUMX日が経過しましたが、仕事の初日に問題が解決していないことに気づきました。

4 日間、ユーザーのページは平均 XNUMX 秒で読み込まれました。 何が問題なのかを見つけたかどうかを尋ねます。

- はい、チケットをオープンしました。
- そして？
- そうですね、彼らはまだ私たちに答えていません。

その時、私がこれまで言われてきたことはすべて、私が戦わなければならない氷山の一角にすぎないことに気づきました。

これによく当てはまる良い引用があります。

「テクノロジーを変えるには、組織を変えなければならないこともあります。」

しかし、私は一年で最も忙しい時期に仕事を始めたので、問題を解決するには、迅速な解決策と長期的な解決策の両方を検討する必要がありました。 そして、今重要なことから始めましょう。

デイ3

したがって、読み込みは 4 秒続き、13 秒から 15 秒が最大のピークとなります。

この期間の XNUMX 日目のダウンロード速度は次のようになりました。

私の観点からすると、何もうまくいきませんでした。 他の人から見ると、いつもより少し遅い速度でした。 しかし、そんなことは起こらず、それは深刻な問題なのです。

私はチームを説得しようとしましたが、チームは単にサーバーを増やす必要があるだけだと答えました。 もちろん、これは問題の解決策ですが、常に唯一かつ最も効果的な解決策であるとは限りません。 なぜサーバーが足りないのか、トラフィックの量はどれくらいなのかを尋ねました。 データを推定したところ、150 秒あたり約 XNUMX 件のリクエストがあることがわかりました。これは原則として妥当な制限内に収まります。

しかし、正しい答えを得る前に、正しい質問をする必要があることを忘れてはなりません。 次の質問は、フロントエンド サーバーは何台あるのかということでした。 その答えは「少し当惑しました」 - フロントエンド サーバーが 17 台ありました。

— 恥ずかしいのですが、150 割る 17 は約 8 になりますか? 各サーバーは 8 秒あたり 160 リクエストを許可しており、明日 2 秒あたり XNUMX リクエストがある場合は、さらに XNUMX つのサーバーが必要になるということですか?

もちろん、追加のサーバーは必要ありませんでした。 解決策はコード自体と表面上にありました。

var currentClass = classes.getCurrentClass();
return currentClass;

機能がありました getCurrentClass()サイト上のすべてがクラスのコンテキストで動作するためです - それはその通りです。 そして、各ページのこの XNUMX つの機能については、 200 件以上のリクエスト.

この方法の解決策は非常に簡単で、何も書き直す必要さえありません。同じ情報を再度要求しないだけです。

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

たった XNUMX 日目で主な問題が見つかったと判断したので、とてもうれしかったです。 私は世間知らずだったので、これは多くの問題のうちの XNUMX つにすぎませんでした。

しかし、この最初の問題を解決すると、グラフは大幅に下がりました。

同時に、他の最適化も行っていました。 修正できる点はたくさんありました。 たとえば、同じ XNUMX 日目に、結局システム内にキャッシュがあることがわかりました (最初はすべてのリクエストがデータベースから直接送られてくるものだと思っていました)。 キャッシュについて考えるとき、私は標準の Redis または Memcached を思い浮かべます。 しかし、そう思ったのは私だけでした。なぜなら、そのシステムはキャッシュに MongoDB と SQL Server を使用しており、データが読み取られたのと同じものだったからです。

XNUMX日目

最初の週は今すぐ解決しなければならない問題に取り組みました。 XNUMX週目のどこかで、私はチームとコミュニケーションをとるために、何が起こっているのか、プロセス全体がどのように進んでいるのかを見るために、初めてスタンドアップに来ました。

またまた面白いものを発見しました。 チームは、18 人の開発者で構成されていました。 テスター8名。 マネージャー3名。 建築家2名。 そして、彼ら全員が共通の儀式に参加しました。つまり、毎朝30人以上がスタンドアップに来て、自分たちが何をしたかを報告しました。 会議に5分も15分もかからなかったことは明らかです。 誰もが異なるシステムで作業しているため、誰も誰の意見にも耳を傾けませんでした。 この形式では、グルーミング セッションあたり 2 時間あたり 3 ～ XNUMX 枚のチケットがすでに良好な結果でした。

私たちが最初に行ったのは、チームをいくつかの製品ラインに分割することでした。 セクションやシステムごとに、開発者、テスター、プロダクト マネージャー、ビジネス アナリストを含む個別のチームを割り当てました。

その結果、次のことが得られました。

• スタンドアップや集会を減らす。
• 製品に関する主題の知識。
• 所有感。 人々が常にシステムをいじっていたとき、自分自身ではなく、他の誰かがそのバグに対処する必要がある可能性が高いことを知っていました。
• グループ間のコラボレーション。 言うまでもなく、QA は以前はプログラマーとあまりコミュニケーションをとっておらず、製品は独自のことを行っていました。 今、彼らは共通の責任を負っています。

私たちは主に効率、生産性、品質に重点を置きました。これらは、チームの変革によって解決しようとした問題です。

XNUMX日目

チーム構成を変える過程で、カウントの仕方を発見した ストーリーPoints。 1 SP は 2 日に相当し、各チケットには開発と QA の両方の SP、つまり少なくとも XNUMX SP が含まれていました。

どうやってこれを発見したのでしょうか?

バグが見つかりました。レポートが必要な期間の開始日と終了日が入力されているレポートの XNUMX つで、最終日が考慮されていません。 つまり、リクエストのどこかに <= ではなく、単に < が含まれていました。 これは XNUMX つのストーリー ポイントであると言われました。 3日.

この後、次のことを行います。

• ストーリーポイントの評価システムが改訂されました。 システムを迅速に通過できる軽微なバグの修正が、より早くユーザーに届くようになりました。
• 開発とテストのために関連するチケットのマージを開始しました。 以前は、すべてのチケット、すべてのバグは閉じられたエコシステムであり、他のものとは結びついていませんでした。 XNUMX ページ上の XNUMX つのボタンを変更すると、ページごとに XNUMX つの自動テストではなく、XNUMX つの異なる QA プロセスを伴う XNUMX つの異なるチケットになる可能性があります。
• 私たちは開発者と協力して人件費を見積もるアプローチを開始しました。 ボタン一つ変えるのにXNUMX日もかかるなんて面白くない。

XNUMX日目

最初の月の半ばあたりで、状況が少し安定し、基本的に何が起こっているのかを理解し、すでに将来を見据えて長期的な解決策について考え始めました。

長期的な目標

• 管理されたプラットフォーム。 各ページにある何百件ものリクエストは深刻なものではありません。
• 予測可能な傾向。 一見すると他の指標とは相関関係のない定期的なトラフィックのピークがありました。なぜこれが起こったのかを理解し、予測する方法を学ぶ必要がありました。
• プラットフォームの拡張。 ビジネスは常に成長しており、ますます多くのユーザーが参加し、トラフィックが増加しています。

昔はよくこう言われました。 「[言語/フレームワーク]ですべてを書き直しましょう。すべてがより良く機能するでしょう!」

ほとんどの場合、これは機能しませんが、書き換えが少しでも機能すれば良いのです。 したがって、次のようなロードマップ、つまりビジネス目標をどのように達成するか (何を行うのか、なぜ行うのか) を段階的に示す具体的な戦略を作成する必要がありました。

• プロジェクトの使命と目標を反映します。
• 主な目標に優先順位を付けます。
• それらを達成するためのスケジュールが含まれています。

これまでは、変更の目的についてチームに話す人は誰もいませんでした。 これには、適切な成功指標が必要です。 当社の歴史上初めて、技術グループの KPI を設定し、これらの指標が組織の指標と関連付けられました。

つまり、組織の KPI はチームによってサポートされ、チームの KPI は個人の KPI によってサポートされます。 そうしないと、技術的な KPI が組織の KPI と一致しない場合、全員が自分自身に責任を負うことになります。

たとえば、組織の KPI の XNUMX つは、新製品による市場シェアの拡大です。

より多くの新製品を投入するという目標をどのようにサポートできるでしょうか?

• まず、欠陥を修正するのではなく、新製品の開発により多くの時間を費やしたいと考えています。 これは、測定が簡単な論理的なソリューションです。
• 第 XNUMX に、市場シェアが大きくなるとユーザーも増え、それに応じてトラフィックも増えるため、取引量の増加をサポートしたいと考えています。

その場合、グループ内で実行できる個別の KPI は、たとえば、主な欠陥の原因となる場所に配置されます。 このセクションに特に焦点を当てると、欠陥が大幅に少なくなることを確認でき、その後、新製品の開発と組織の KPI のサポートにかかる時間が増加します。

したがって、コードの書き換えを含むすべての決定は、会社が設定した特定の目標 (組織の成長、新機能、採用) をサポートするものでなければなりません。

このプロセス中に、興味深いことが明らかになり、技術者だけでなく社内全般でニュースになりました。すべてのチケットは少なくとも XNUMX つの KPI に焦点を当てなければなりません。 つまり、製品が新しい機能を作りたいと言う場合、最初に「この機能はどのような KPI をサポートしますか?」という質問をする必要があります。 そうでない場合は、申し訳ありませんが、不要な機能のようです。

XNUMX日目

月末に、私は別のニュアンスを発見しました。それは、運用チームの誰も、私たちがクライアントと締結した契約を見たことがないということです。 なぜ連絡先を表示する必要があるのか​​と疑問に思われるかもしれません。

• まず、SLA は契約で指定されているためです。
• 次に、SLA はすべて異なります。 各クライアントは独自の要件を持っていましたが、営業部門は何も確認せずに署名しました。

もう 1 つの興味深いニュアンスは、最大手のクライアントの XNUMX つとの契約では、プラットフォームでサポートされるすべてのソフトウェア バージョンが n-XNUMX、つまり最新バージョンではなく最後から XNUMX 番目のバージョンである必要があると規定されていることです。

プラットフォームが ColdFusion と、1 月にまったくサポートされなくなった SQL Server 2008 に基づいていた場合、n-XNUMX からどれだけ離れていたかは明らかです。

XNUMX日目

XNUMXか月目の半ば頃には、座って何かをするのに十分な時間ができました。 値流れマッピング プロセス全体に対して完全に。 これらは製品の作成から消費者への届けまでに必要なステップであり、できるだけ詳細に説明する必要があります。

プロセスを小さな部分に分割し、何が時間がかかりすぎているのか、何が最適化、改善できるのかなどを確認します。 たとえば、製品リクエストがグルーミングを通過するのにどれくらい時間がかかりますか、開発者が取得できるチケットにいつ到達するか、QA などです。 したがって、個々のステップを詳細に見て、何を最適化できるかを考えます。

これを実行したとき、次の XNUMX つのことが目に留まりました。

• QA から開発者に返されるチケットの割合が高い。
• プルリクエストのレビューに時間がかかりすぎました。

問題は、これらの結論が次のようなものであったことです。「かなり時間がかかるようですが、どれくらい時間がかかるかはわかりません。」

「測定できないものを改善することはできません。」

問題の深刻さをどうやって正当化するのでしょうか? 何日も、あるいは何時間も無駄にしているでしょうか?

これを測定するために、Jira プロセスに「ready for dev」と「ready for QA」といういくつかのステップを追加して、各チケットの待機時間と特定のステップに戻る回数を測定しました。

また、レビュー対象のチケットの平均数を知るための「レビュー中」も追加され、そこからダンスを始めることができます。 システム メトリクスがありましたが、新しいメトリクスを追加して以下の測定を開始しました。

• プロセス効率: パフォーマンスと計画/納品。
• プロセス品質: 欠陥の数、QA からの欠陥。

何がうまくいっていて、何がうまくいっていないのかを理解するのに非常に役立ちます。

XNUMX日目

もちろん、これはすべて良いことであり、興味深いことですが、XNUMXか月目の終わりに向かって、私はそのような規模を期待していませんでしたが、原則として予測可能な何かが起こりました。 経営トップが変わったから人が辞め始めた。 新しい人が経営陣に加わってすべてを変え始め、古い人たちは辞めました。 そして、設立から数年の会社では通常、全員が友人であり、全員がお互いのことを知っています。

これは予想されていたことだが、解雇の規模は予想外​​だった。 たとえば、XNUMX 週間で XNUMX 人のチームリーダーが同時に自らの自由意志で辞任を提出しました。 したがって、他の問題を忘れるだけでなく、次のことに集中する必要がありました。 チームを作る。 これは解決するのが長くて難しい問題ですが、残った人々（または彼らのほとんど）を救いたかったので、対処する必要がありました。 チームの士気を維持するには、人々が去ったという事実に何らかの形で対応する必要がありました。

理論的には、これは良いことです。つまり、チームのスキルを評価して人材を置き換えることができる、完全な白紙の権限を持った新しい人が入ってくるのです。 実際、さまざまな理由から、単に新しい人を受け入れることはできません。 常にバランスが必要です。

• 古くて新しい。 私たちは、変化を起こし、使命をサポートできる高齢者を維持する必要があります。 しかし同時に、新しい血を取り入れる必要もあります。それについては後ほど説明します。
• 経験。 一緒に働きたいという意欲のある優秀な後輩たちとたくさん話しました。 しかし、後輩をサポートし、指導してくれる先輩が不足していたため、引き受けることができませんでした。 まずトップを採用し、それから若者を採用する必要がありました。
• アメとムチ。

適切なバランスとは何か、それをどのように維持するか、何人を維持し、どの程度プッシュするかという質問に対する良い答えはありません。 これは純粋に個人的なプロセスです。

XNUMX日目

私は自分のチームを理解するためにチームを注意深く観察し始めましたが、もう一度次のことを思い出しました。

「ほとんどの問題は人間の問題です。」

チーム自体 (開発と運用の両方) に XNUMX つの大きな問題があることがわかりました。

• 現状への満足度。
• 責任感の欠如 - なぜなら、パフォーマーの仕事の結果をビジネスに影響を与えるほどもたらした人は誰もいないからです。
• 変化への恐怖。

変化は常にあなたを快適ゾーンから連れ出します。若者ほど変化を嫌います。理由も方法も理解できないからです。 私が聞いた最も一般的な答えは、「そんなことはしたことがない」です。 さらに、それは完全に不条理な点に達しており、誰かが憤慨しなければ、ほんのわずかな変化も起こりません。 そして、その変化が彼らの仕事にどれほど影響を及ぼしたとしても、人々はこう言いました。 これではうまくいきません。」

しかし、何も変えずに改善することはできません。

私はある従業員とまったくばかげた会話をし、最適化に関する私のアイデアを彼に話したところ、彼は私にこう言いました。
- ああ、去年のは見ていなかったね！
- だから何？
「今は以前よりずっと良くなりました。」
- それで、これ以上良くなることはできないのですか？
- なんで？

良い質問です - なぜですか? あたかも今が以前よりも良くなっているなら、すべてが十分にうまくいっているかのようです。 これは責任の欠如につながりますが、これは原理的にはまったく正常なことです。 先ほども言いましたが、技術グループは少し傍観していました。 会社は存在すべきだと信じていたが、 誰も基準を設定したことはありません。 テクニカル サポートは SLA を一度も見たことがなかったので、グループにとってはまったく「受け入れられる」ものでした (これが私にとって最も衝撃的でした)。

• ロード時間は 12 秒。
• リリースごとに 5 ～ 10 分のダウンタイム。
• 重大な問題のトラブルシューティングには数日から数週間かかります。
• 24 時間 7 日対応の当直担当者不足。

もっとうまくやったらどうだろうかと問う人は誰もいないし、そうである必要はないことに気づいた人もいない。

おまけに、もう XNUMX つ問題がありました。 経験不足。 先輩たちが去り、残った若手チームは前体制下で育ち、それに毒された。

これらすべてに加えて、人々は失敗し、無能だと思われることも恐れていました。 これは、第一に、次のような事実によって表されます。 いかなる状況であっても助けを求めることはありません。 私たちはグループとして、または個別に何度話し合って、「やり方がわからない場合は質問してください」と言ったことでしょう。 私は自分に自信があり、どんな問題でも解決できることを知っていますが、時間がかかります。 そこで、10分で解決できる方法を知っている人に質問できるなら質問します。 経験が少ないほど、無能だと思われるのではないかと思うと、質問するのが怖くなります。

質問することに対するこの恐怖は、興味深い形で現れます。 たとえば、「このタスクの調子はどうですか?」と尋ねます。 - 「あと数時間、もう終わっています。」 翌日、もう一度尋ねると、すべて問題ありません。ただし、問題が XNUMX つありました。その日の終わりまでに必ず準備が整います。という答えが得られます。 さらに一日が経過し、壁に釘付けになって誰かと話すことを強制されるまで、これが続きます。 人は問題を自分で解決したいと考えていますが、自分で解決しなければ大きな失敗になると信じています。

だからこそ 開発者は見積もりを水増しした。 それと同じ逸話ですが、ある仕事について話し合っているときに、彼らが私に非常に驚いたような数字をくれたのです。 開発者の見積もりには、QA でエラーが見つかるためチケットが QA から返されるまでの時間、PR にかかる時間、レビューする人が作業するまでの時間も含まれていると聞きました。それは忙しいでしょう - つまり、すべて、可能な限りのことです。

第二に、無能だと思われることを恐れている人 過剰分析する。 具体的に何をしなければならないかを言うと、「いや、ここで考えてみたらどうなるでしょうか？」ということになります。 そういう意味では、当社が特殊なわけではなく、若者にとってはよくある悩みです。

それに応えて、私は次の実践方法を導入しました。

• ルールは30分。 XNUMX分以内に問題を解決できない場合は、誰かに助けを求めてください。 人々はまだ尋ねていないので、これはさまざまな程度の成功を収めて機能しますが、少なくともプロセスは始まっています。
• 本質以外はすべて排除する、タスクを完了する期限を見積もるとき、つまり、コードを書くのにかかる時間だけを考慮します。
• 生涯学習 分析しすぎる人へ。 それは人々との継続的な仕事だけです。

XNUMX日目

そうこうしているうちに、予算を決める時期が来ました。 もちろん、お金を使ったところでは面白いことがたくさん見つかりました。 たとえば、別のデータセンターにラック全体があり、2 つの FTP サーバーがあり、それを XNUMX つのクライアントが使用していました。 結局のところ、「...私たちは引っ越しましたが、彼はそのままで、私たちは彼を変えませんでした。」 XNUMX年前のことです。

特に興味深かったのはクラウドサービスの請求書だ。 クラウド料金が高額になる主な理由は、開発者が生まれて初めてサーバーに無制限にアクセスできるようになったためだと私は考えています。 「テスト サーバーをください」と頼む必要はなく、自分で取得できます。 さらに、開発者は常に Facebook や Netflix が羨むようなクールなシステムを構築したいと考えています。

しかし、開発者には、以前は必要なかったサーバーの購入経験や、サーバーの必要なサイズを決定するスキルがありません。 そして、彼らは通常、スケーラビリティとパフォーマンスの違いを完全に理解していません。

在庫結果:

• 私たちは同じデータセンターを去りました。
• ログサービス3社との契約を終了しました。 なぜなら、私たちはそれらを 5 つ持っていたからです。何かをいじり始めた開発者は皆、新しいものを採用しました。
• 7 つの AWS システムがシャットダウンされました。 繰り返しになりますが、中止されたプロジェクトは誰も止めず、すべて作業を続けました。
• ソフトウェアのコストを 6 分の XNUMX に削減。

XNUMX日目

時が経ち、XNUMXか月半後に取締役会を開かなくてはならないことになりました。 当社の取締役会は他の取締役会より優れているとか劣っているということはなく、すべての取締役会と同様に、すべてを知りたいと考えています。 人々は資金を投資しており、私たちが行っていることが設定された KPI にどの程度適合するかを理解したいと考えています。

取締役会は毎月、ユーザー数、その成長、ユーザーがどのようなサービスをどのように使用しているか、パフォーマンスと生産性、そして最後に平均ページ読み込み速度など、多くの情報を受け取ります。

唯一の問題は、平均は純粋な悪であると私が信じていることです。 しかし、これを取締役会に説明するのは非常に困難です。 彼らは、たとえば XNUMX 秒あたりの読み込み時間の分散などではなく、集計された数値を扱うことに慣れています。

この点に関しては、いくつか興味深い点がありました。 たとえば、コンテンツの種類に応じて、トラフィックを別々の Web サーバー間で分割する必要があると言いました。

つまり、ColdFusion は Jetty と nginx を経由してページを起動します。 また、画像、JS、CSS は、独自の構成を持つ別の nginx を通過します。 これは私が話しているかなり標準的な習慣です 私が書きました 200〜XNUMX年前。 その結果、画像の読み込みが大幅に速くなり、平均読み込み速度が XNUMX ミリ秒増加しました。

これは、グラフが Jetty に付属のデータに基づいて構築されているために発生しました。 つまり、高速コンテンツは計算に含まれておらず、平均値が跳ね上がっています。 これは私たちには明らかで、私たちは笑いましたが、なぜ私たちが何かをしたのに状況が 12% も悪化したのか、取締役会にどう説明すればよいでしょうか?

XNUMX日目

XNUMX か月目の終わりに、私はまったく当てにしていなかったものが XNUMX つあることに気付きました。それは時間です。 私が話したことはすべて時間がかかります。

これは私の実際の週間カレンダーです。ただの仕事週間であり、あまり忙しくありません。 すべてをやるには時間が足りない。 したがって、繰り返しになりますが、問題への対処を支援してくれる人材を採用する必要があります。

まとめ

それがすべてではありません。 この話では、私たちがどのように製品に取り組み、一般的な波に同調しようとしたのか、技術サポートをどのように統合したか、他の技術的な問題をどのように解決したかについてはまだ触れていません。 たとえば、データベース内の最大のテーブルでは使用していないことをまったく偶然に知りました。 SEQUENCE。 自作関数があります nextID、トランザクションでは使用されません。

似たようなことは他にも何百万件もあり、それについては長い間話し合うことができました。 しかし、それでも言わなければならない最も重要なことは文化です。

他のすべての問題を引き起こすのは、文化またはその欠如です。 私たちは、人々が次のような文化を築くことを目指しています。

• 失敗を恐れない。
• 間違いから学ぶ;
• 他のチームと協力する。
• イニシアチブを取ります;
• 責任を負います。
• 結果を目標として歓迎する。
• 成功を祝う。

これで他のすべてが実現します。

レオン・ファイアー ツイッターで, フェイスブック と ミディアム.

レガシーに関しては XNUMX つの戦略があります。それを何としても扱うことを避けるか、関連する困難を勇敢に克服するかです。 私たちは、 DevOpsConf 私たちはプロセスとアプローチを変更する XNUMX 番目の道を選択しています。 ぜひご参加ください ユーチューブ, メーリングリスト и 電報、そして私たちは一緒にDevOps文化を実装していきます。

出所： habr.com