何年も前、私は疲労から技術的な廊下の壁に寄りかかり、ゆっくりとそれに沿ってcraい始めました。 締め切りに間に合うように、数週間の残業の後にプロジェクトを引き渡しました。 私のリーダーは通り過ぎました、私はうめきました：
-ローマ、私はエンジニアにうんざりです。 帰ります！
彼は愛情を込めて微笑んで言った：
-いいね。 システムアーキテクトになります。 光と純度だけがあります。 十分な睡眠をとって来て、あなたが何をするか教えてあげましょう。
私は若くて素朴でした。 彼は寝て来た。 その後、彼は徐々に建築家になり始めました（今では彼になっています）。私は安全に言うことができます。エンジニアの日常生活と同じくらい多くの光と純度があります。 しかし、より多くの責任があります。 そのため、目的を理解できなければ、建築家である必要はありません。
しかし！ 理解すれば、これは非常にエキサイティングな冒険になります。
どのように見えますか？
一般的に、顧客とコミュニケーションを取り、彼らが本当に必要なものを自分で見つけ、頭の中やインフラストラクチャーにあるものを見つけ、それから大規模なプロジェクトを作成すること、そしてすべてが美しいことは興味深いと思われました。
現実とのギャップは、彼らが頭の中に持っているものが、彼らが彼らのインフラストラクチャに持っているものと常に相関しているわけではないということです。
そして最初に心理学者として働き、それから真実をもたらし、それから気分を害する（時々）、そして再び心理学者として働き、そしてあなたは百の質問をし、そして事実をチェックします（そしてそれらのすべてが提示されているわけではありません）-そして意見が形成された後、システムの設計方法。 それから、それに興味のあるすべての人々に説明します。なぜそうなのか、なぜ、どれくらいの費用がかかるのか、そういう状況に対してどれだけ正しいのか、そして「どうしてもっと速く動く」、「10年かかる」フォワード」は同じテクノロジー上にあるかもしれませんが、そうではないかもしれません。 そして、選択方法。 そして、肝臓が大きくなると、フクロウを描くだけになります。実際、システムを詳細に設計します。
専門職の最大の喜びは、最初にデザインを完成させ、すべてがタスクに必要なとおりであることを理解することです。 そして、数年後、これがチーム（または多くのチーム、数百人まで）によってどのように具体化されるかを確認し、それを見て、それを行う方法を示したことを嬉しく思います。
一般に、アーキテクトはプロジェクトの主要な決定を行う人です。 おそらく、これが私を職業にする最も重要なことです。
建築家は一般的に何をしますか？
現在、クライアントプロジェクトとCloud Technoserv Cloudに従事しています。 エンターテインメントは次のようになります。主要なプロジェクトがいくつか到着します。 たとえば、データセンターを設計します。
誰かがデータセンターを描いています。 誰かがデータベースに精通している。 誰かがオンラインです。 このすべてにおいて、プロジェクト全体に対する顧客のより高いレベルの要件を理解している人が必要です。 顧客は、データセンターを構築したり、何らかのシステムを導入したりすることを望んでいません。 彼の仕事は、「すべての負荷をある場所から別の場所に移動したい」または「すべてのシステムが災害に耐えられるようにするフォールトトレラントプラットフォームを編成したい」です。 これらの要件をすべて理解している人が必要です。 そして、それらはまだ要件でさえなく、ただのウィッシュリストです。 「売り上げを2倍に増やし、同時にインシデントの数を3倍に減らしたい」-適切な人と話をして、彼らがどこから多くのインシデントを得たのか、何ができるのかを理解する必要があります。
つまり、ウィッシュリストが最初に集まります。 次に、技術仕様がまとめられ、合意された後、物理学と適用部分の両方を含む決定が行われます。これらすべてのタスクにはアーキテクトが必要です。
アーキテクトがすべてのサブシステムのプロジェクト全体を作成するわけではありません。大規模なもの、評議会のシステム、またはチーフスペシャリストの指導の下で責任を負う領域についてです。 たとえば、プロジェクトのVKS（SCS）を設計および構築する必要がある場合、ネットワークアーキテクトが関与します。 ある種の情報システムを開発する必要がある場合、応用アーキテクトが関与します。 などなど。
説明する最も簡単な方法はクラウドです。 会社がクラウドから販売するすべてのものの初期設計を行います。 私は自分のインフラストラクチャの構築を計画および設計（そして制御）し、それを運用チームに引き渡します。 3人の人々がサブタスクで私と協力しています。彼らはOpenStack、VMware、ストレージネットワークを担当しています。
hemoはどこにありますか？
ケースの85％のどこかで、ビジネスは彼が望むものの半分を信じており、私たちは彼にすでに持っていると言います-そして問題はありません。 ただし、部門、部門などのレベルに下がると、すべてがそれほど面白くないことがわかります。プロセスはビジネスによって作成されます（「プロセスでITILを完全に実行し、リクエストはシステムでのみ調整され、すべてがスキップしますすぐに "）、DBMS管理者は、セキュリティガードがすべての企業幹部によって署名された紙のコピーをまだ要求していることを発見します。 彼らはこの紙片を何ヶ月も分析し、その後、ある種のテスト環境を展開するための青信号を出します。
キャッチは、あなたがすべてがあなたのために働いていないという文言でプロジェクトでビジネスに来た場合、あなたがこのプロジェクトに受け入れられないように祈ることです。
あなたがこれで「燃やした」人はあなたを働かせないからです。
特に、あなたは時々、背後に隠れるために常に一枚の紙を持たなければならないそのような古代の科学者がいる。
そして、はい、私はこれらすべてがどのように変更できるかを理解するのが好きです。
プロジェクトはビジネスと一緒にしか評価できず、数年後に評価できます。 しかし、まさにプレゼンテーションには主観的な要素があります。まあ、飛行機は飛んでいて美しくなければなりません。 また、そのような結果は理想的にはテンプレートになり、同様のすべての場合に実装できるようになります。
燃え尽きる方法
市場は小さく、誰もが誰でも知っています。 蓄積された疲労と責任のために、人々はただどこかに去るだけです。 人々が苦しむことは起こります。 たとえば、私は非常に強力な技術専門家を知っています。 彼は来て、すべてを良いわいせつで覆います。
彼は言う：「地球はあなたをどのように身に着けているのか、そのような馬鹿！」そして彼はコードを分析し、証明する。 しかし、彼は彼のプロ意識のために愛されています。 彼は決して建築家になりたくなかった、「彼らが感じる意味や発散の色合いを翻訳したくない」と言います。 そして、今日までエンジニアのままです。 「TKがあります。 私は連れて行って行きました。 彼がそれを必要としているかどうかさえ知りたくありません。」
別の同僚が技術サービスを指揮し、次に建築部門を指揮し、現在は熱帯の島から遠隔管理に従事しているようです。 ハッピー。
そのため、アーキテクトが開発者の開発部門であると考えている場合、チームリーダーの直後はわかりません。 ご覧のように、hemoはたくさんありますが、難しい問題を見つけて解決した喜びはたくさんあります。 しかし、すべてのプロジェクトがすべて大規模であるため、喜びは年に数回来ます。
「もし私が間違ったら？」
テレコムITディレクターはかつて尋ねました：「私が間違ったら、私を訂正しますか？」
「はい」、「私たちは話します」と言います。
彼：「そして、どうやって私を納得させますか？」
私は言います。 銃はあなたと一緒です。 あなたが足で自分自身を撃った場合、あなたはおそらく傷つくだろうと言うことができます。」
しかし、私はいつも銃が脚を指していることを警告します。
または、ここに例があります。 仮想化されたアプリケーションがあり、負荷はケースからケースへジャンプします。 クライアントは小売店であり、3月8日までに急いでいます。 バックエンドは成功し、サイトは404になります。すべてが単純です。アプリケーションを並列プロセスに分散するだけで、ボトルネックがないことを考慮してください。 そして、それは90年代に書かれ、それ以来シェルで草に覆われました-変換するものがたくさんあります。 その後、ビジネスの人々は変わりました。「余分なサーバーを購入し、コンセプトから生きていきましょう。そうすれば、その能力はピークに十分です。」 私たちはラックを数台購入し、1年365日のうち320日空転させました。 2年後、これらの叔父は去り、新しいおじが到着した。 彼らはラックを見て、「なぜ空気を温めるのか、売りましょう」と言います。 売る。 突然、春が来ます。 最初の反復が再び始まります。 その結果、彼らはクラウドに行き、私の同僚は彼らが正しくインストールするのを助け始めます。 誰もがバランサーとは何かを理解しているわけではありませんが、ここでは操作を詳細に伝える方が良いと思います。
多くの場合、2か月間、コストをかけずにプロジェクトを迅速に立ち上げる必要がありますが、実際、動物園を分解すると、プロジェクトを10年間ビルドしなければならないことがわかります。 時々伝えることが可能です。 時にはそうではない-顧客は年間計画を立てて考え、これが彼のお金と彼のビジネスです。 彼は正しい、彼はビジネスで戦略的に何をすべきかを知っている。 私の仕事は、最もわかりやすい数字または定義で、それぞれの選択肢と、それぞれの長所と短所を彼に示すことです。
そして時々、私たちは新興企業にからかわれます-プロトタイプを立ち上げることがますます多くなり、それから恒久的な部品に作り直し始めます。
誰が引くことができますか？
彼らがどのように建築家になるのか分かりません。 私はエンジニアとして4年間働いた後、別の会社（既に経験がある）で働いていたと言えます。デザイナーとして、次に建築家として。 Technoservで2年半。 しかし、「反対側」では、請負業者の人々と同じように、テクノサーブのエンジニアと仕事をしました。彼らは1つの大きなプロジェクトを行いました。
もちろん、ほとんどのアーキテクトは、高度な開発者とエンジニアから成長します。 しかし、例外はほとんどありません。それはすべて、システム思考のスキルに依存します。これは一般に、IT専門分野で必ずしも習得されるとは限りません。
アーキテクチャの多くは、新しいテクノロジーを求めています。 システムの設計と構築に対する一般的なアプローチは変更されていません。 何を実装し、何を計画するかは、準備の問題です。 かなり限られた期間、ベンダーのソリューションをポートフォリオに含めることができます。 たとえば、データベース、アプリケーション、ネットワーク、ユーザートランザクション、データセンターの監視があります-原則として、アプローチは同じです。 経験（多くの経験）と体系的思考を決定します。
チームとして新しいアーキテクトにインタビューしなければならなかった場合、私は顧客とエグゼキューターとの状況を失うことを好むでしょう：私はタスクを設定するか、むしろ顧客がよくするようにウィッシュリストを声に出してから、申請者が私に尋ねる質問、タスクがどのように見つけられるかを見ます提供しています。
テクノロジーの開発において、知識はすぐに時代遅れになり、アルゴリズムの文化とスキルは永遠に残ります。 そして、建築では、知識のほとんどは時代遅れになりません-何かを勉強することで、1年、5年、10年で多くのことが役に立つと確信できます。
建築家に行くために必要なことを理解する方法は？
知りません おそらく、人々とコミュニケーションを取り、多くの要因で複雑な問題を解決するというスリルが欲しいときです。 または、まだプロジェクトのアーキテクトとして活動している場合、この役割は異なると呼ばれるものになります。
一般的に、来て。 ここでは、光と純度だけがここにあると彼らは言います。
これは私たちの建築家アレクサンダーシュビンの材料です。