最近の議論の1つで、IT企業の仕事を文明化する主なシステムをリストしました。 このリストは非常に広範であったため、独立した記事としてデザインすることにしました。



同様の設計は多くの企業で見ることができ、さらに、これらのシステムの一部が長い間存在していなかった企業を観察しました。解決できない絶え間ない問​​題のため、これらのシステムは自然に現れ始めました。



以下のすべては、有資格者が働く企業/部門に適用されます。つまり、「初心者向けオフィス」コースは必要ありません。 ワークステーションのグループポリシーや、デスクトップのショートカットを変更したり、お気に入りのプログラムをインストールしたりするための特別な管理者は必要ありません。 つまり、これはITスペシャリストのバックオフィスであり、他の部門のバックオフィスとは大きく異なります。



簡単なコンテンツスポイラー：VCS、ソースコードリポジトリ、コードレビュー、ビルドサーバー、CI、タスクトラッカー、Wiki、企業ブログ、機能テスト、パッケージリポジトリ、構成管理システム、バックアップ、メール/ジャバー。



議論中のインフラストラクチャの断片の写真：







それでは、簡単なものから始めましょう。



職場：各職場用のボタン（約90〜100個）を備えたコンピューター。 外部/ 2/3モニターも望ましいです。 一般的に使用されるラップトップ、非常に広く-MacBooks。 ユーザーは自分のマシンにadminまたはsudoを持ち、エディター、デバッガー、電子メールクライアント、ブラウザー、ターミナルなどを含む便利なソフトウェアのセットを自分で決定します。



インターネット。 通常、オフィスのWiFiとBYOD（言い換えれば、オフィスのWiFi'emを悪用するラップトップ、タブレット、携帯電話を自由に持ち込みました）。 多くの場合、有線ネットワークがまったくない場合があります。 すべての通信が暗号化されるため、このようなネットワークのセキュリティは条件付きです。 インターネットには多くのことが必要です。 そして、勤務時間中のYouTubeのシールだけでなく、突然緊急の「今すぐパッケージバージョンを比較するために、原材料を含むDVDをダウンロードする」ためにも。 ちなみに実生活から。 あらゆる種類のスタックオーバーフローやその他のITリソースを考えると、インターネットは無制限で制御されず、高速であるほど良いはずです。



シンプルなものを運転しました。 さらに深刻です。



バージョン管理システム （VCS）は一般的である必要があり、「それぞれに」はここでは機能しません。 事実上の標準は、前世紀のsvn / cvs / vcsからのgit 、条件付きで人気のある水銀（hg）、エキゾチックバザー（bzr）です。 さらに、ワイナリーには独自の世界があり、他にも何かがあります。



バージョン管理システムはローカルで動作するため、誰もがプッシュする（プッシュする必要がある） 中央ソースコードリポジトリが必要です。 gitlabは非常に人気があります。 独自のソリューションがあり、自分を育てるのが面倒な人のためのgithubがあります。 彼女は2番目に重要なこと、プル要求を決定します。 そのため、ある人がメインブランチ（共有リポジトリ）に到達する前に別の人が何をしたかを見ることができます。 コードレビューがそのように実行されない場合でも、プルリクエストは意味があることに注意してください。 原理は単純です-1つは書き、もう1つはsmerdzhil（マージ）です。



コードが複雑な場合は、 コードレビューのためのシステムが必要です。 コードレビューとは、プログラマー（またはシステム管理者-devops、すべて）が互いのコードを確認することを意味し、コードを受け入れるための正式な手順があります-たとえば、「少なくとも2人が見て、承認する必要があり、そのうちの1人はシニア/リードでなければなりません」 例：gerrit、Crucible。 複雑さがエッジでバランスを保っている場合、gitlabのコメントで議論しながら、自発的に契約に準拠しようとすることができます。 しかし、ロボットが従わないすべてが自発的であるように、それは時々失火します。



最小形式の人々のチームの管理は、 タスクスケジューラ （タスクトラッカー）（redmine、jira、mantis）を介して実行されます。 ほとんどの場合、 バグトラッカーの役割も実行します。 主な目標は、問題のステートメントを形式化し、あいまいさを取り除き、誰かが間違ったことをしたときに加害者を見つけることです（あなたはそれを言ったのですか？いいえ、あなたはそれを理解しませんでした！-その後、タスクテキストが見え、誰が見逃したかが明らかになります）。 タスクトラッカーの場合、特にヘッド/チームリーダーから、言葉の法律を慎重に排除する必要があります。 何か変更する必要がありますか？ タスクを設定します。 官僚主義の量は最小限であり、混ofの量は倍に減少します。



wiki -mediawiki、moin-moin、confluence、dokuwiki-他のチームメンバーに表示される記事を書くことができ、他の人の後に編集できるものはすべて、自分のwikiを持つことがほぼ必須と考えることができます。 「これを行う方法」、規制、討議結果、計画されたアーキテクチャソリューション、他の方法ではなくこの方法でこれが行われる理由を説明するテキストを折り畳むのに理想的な場所です。 よく構成されたウィキは良いですが、テキストの乱雑な山でさえ、「これをすべて知っていた」退職した従業員とともに消えていく口承の伝統よりも数倍便利です。



ウィキがブログをサポートしている場合、ウィキでのブログの形式に同意するか、社内ブログのために何かを上げる必要があります。 そのようなブログに何を書くべきですか？ 構成に奇妙なバグを見つけるのに4時間かかりましたか？ ブログで説明してください-次回は自分で検索するので、すぐに読むことができますが、ゆっくりと読んでください。 頭の中に完全には収まらない長い長い問題に対処し始めましたか？ ノートブックとしてのコンピューター上のテキストエディターの代わりに、wikiに書き込みます。 同僚の1人が既に書かれた内容を読んで、デバッグの過程で短い解決策を言うことが判明する場合があります。 そして、ある時点で、同社のブログはおそらく困難な状況で最も価値のあるリソースになるでしょう（インターネットの後の第2）。



それが書かれたワークステーションで動作するコードを書くことは、まれな贅沢です。 ほとんどの場合（さらに、より多くの場合）、コードはミドルウェアであり、他の大きなサーバーコード間のレイヤーであり、生産的な作業のために広範な環境を必要とします。 「このデバッグアプリケーションには、作業ベース、memcached、redis、snmpをスイッチにコピーしたmysqlが必要です。」 ワークステーションでこのような環境を構築することは今でも楽しみです。 そして、いくつかのプロジェクトがあり、それぞれに独自の環境があります。



したがって、私たちは最初の難しいことを得ます： プログラマーの略です 。 実際には、USB接続のマイクロコントローラーまたはhadoopサーバーファームになります。 プログラマが自分の立場を持っていることが重要です。これは、プログラマが書いたように、プログラマが自分の作業の結果をすぐに確認できる作業構成に少なくともある程度似ています。 節約する価値はありません。各プログラマーは自分の立場を持つべきです。 コストが高すぎる場合-mocapasを調達する必要があり、mocapasを調達できない場合、会社に問題があります-プログラマーは「本番」で、複数のプログラマーがいる場合は同時に書き込みます。 プログラマが本番環境に入ることを許可されていない場合、彼らは盲目的に書き込みます-生産性にさよなら。



次に、本番環境でコードがどのように表示されるかという問題があります。 ほとんどの場合、これらはパッケージ（deb / rpm）、実行可能ファイル（exe）、または退屈なもの（html）です。 パッケージに「退屈な静的要素をラップする」ことも理にかなっていることに注意してください。 オタクから直接拡散するチームがあります（特定のブランチ、タグ、またはマスターであり、他のブランチで開発が行われることを前提としています）。



パッケージを構築することは、特にコードがゼロから書かれていないが、既存の構成と他の多くのパッケージに依存している場合、非常に複雑で複雑になる可能性があります。 パッケージビルドシステムを設定するのは理にかなっています 。 これを行うには、最小限の構成でCI（継続的統合）を使用します。多くの場合、手動で制御します（インターフェイスに移動して、パッケージアセンブリの[タスクを実行]をクリックします）。 オープンソースの標準はジェンキンスです。 最も有名なプロプライエタリなもの-チームシティ。 最小構成では、指定されたブランチ/タグ/リポジトリを取得してパッケージを収集します。 CIのインターフェースからダウンロードできます。



しかし、誰もがaptitudeのインストールに慣れているため、 ミラーまたはパッケージリポジトリを上げる必要があります 。 同じCIがパッケージをリポジトリにアップロードできます。 マウスでクリック-リポジトリが接続されているすべてのサーバーにソースコードを配置できます。 リポジトリの存在により、多数のサーバー上のアプリケーションを自動モードまたは半自動モードですばやく「ロールアウト」でき、さらに実験/テスト/本番/旧安定に分離できることに注意してください。 また、パッケージマネージャーはインストールされたファイルの整合性を検証するために必要なすべてのツールを備えており、パッケージを再度ダウンロードして変更されたファイルを復元できるため、非常に迅速に損傷を修復することができます（WordPressのあらゆる種類の悪のバックドアがお気に入りのphpファイルを台無しにするWebマスターに注意してください） アセンブリ中にディストリビューションにないパッケージが必要な場合は、パッケージもパッケージ化する必要があります。 上昇はpypiの稼働時間に依存しますが、生産は悲しい光景です。 依存関係の一部は、アセンブリ中にのみ関連する場合があることに注意してください;この場合、サーバーへの使用済みパッケージディレクトリのレプリケーションを構成するのが理にかなっています。



CIは同時に、テストを実行できます。 ユニットテストは、ほとんどの場合、パッケージアセンブリの段階（コンパイル後）で実行されます。 ただし、機能（受け入れ）テストの場合は、 テスト環境 （1つまたは複数）を上げる必要があります 。 コンパイルが正常に完了すると、スタンドへのパッケージのインストールと操作性のテストが開始されます。 会社にリソースがあれば、奇妙なバグごとにテストが行​​われ、それをキャッチします。 最小限の形式では、基本的なハッピーパスをチェックする必要があります。つまり、「クライアントは来て、商品を見て、バスケットに入れて、支払いと購入ができます」。 悲しいパス（クライアントにお金がない/カーネルバージョンがモジュールに対応していない）も確認できますが、それははるかに多くのリソースです。 しかし、ハッピーパステストでも安定性は大幅に向上します。



多数の構成とテストがある場合、コードレビューシステムとテストの統合を高めることは理にかなっています 。 最も有名なものは、ゲルをジェンキンに結合するズールです。 この場合、コードレビューの提案は、プログラマー（システム管理者）のコミットがテストに合格した後にのみ送信されます-膨大な数の単純なバグが「正気との戦い」段階でキャッチされることは言うまでもなく、人々の時間が節約されます これが何百人もの独立した開発者でどのように機能するかの理想的な例は、オープンスタックプロジェクトインフラストラクチャです。



テストが構成されている場合、コードレビューは解決され、常に以前のバージョンが存在します。その後、 継続的な統合 、その本来の意味、つまり、テストとコードレビューが合格した直後に本番環境に変更を自動的にロールアウトすることを考えるのが理にかなっています。

最終和音

これには通常、メール、jabber（タスクトラッカーとCIをリンクするとよいでしょう）、おそらくメールが必要です。 vpnサーバーを上げて、閉じたポートなどで問題なくどこからでも作業できるようにするのが理にかなっています。



Google Mailがあるのになぜ「あなた」なのですか？ Googleがグループアドレスのバルクメッセージを好まないため、彼らが不可解にnagiosからの手紙を受け取らないようになると、Googleとの戦いはメールサーバーよりも長くかかる可能性があるためです。



そしてもちろん、これにはすべて独自のメタインフラストラクチャが付属しています。

1. これはすべて設定する必要があります。 心の中- 構成管理システム 。 シェフ、パペット、アンシブル、ソルトスタック。
2. これはすべて監視する必要があります。 監視 -nagios、shinken、zabbix、icinga
3. これはすべてバックアップする必要があります。 はい、リポジトリもバックアップする必要があります。「最新バージョンを持っている」開発者から20〜30のリポジトリを収集するのは楽しいからです。 また、マージリクエストのコメントは一般に回復不能です。
4. これにはすべてドメイン名が必要です。ドメインまたはサブドメインが部門を完全に制御している方がよいので、新しいAレコードごとに「さあ、DNSに別のスタンドを追加する」必要はありません。 独自のDNSは、自動的にレコードを生成する別の重要な機会を開きます（たとえば、サーバーのipmi-interfacesのアドレス用）

これは、質の良いIT企業を擁する控えめな経済です。 これらは機能するツールであり、「ユーザーディレクトリ」（および一般に、認可の問題は扱われなかった）、アクセス制御システム、時間追跡、給与、事業計画など、開発者/システム管理者が必要としないものはありませんが、利害関係者に。

そして、それはいくらですか？

工数で、s / nを掛けると思います。 数値は非常に近似しています（つまり、天井から取られています）。

• 従業員の職場-1人あたり8時間（通常は「最初の就業日」にカウントされます）
• gitlab-4〜8時間
• gerrit-16-24時間
• ジェンキンス（ベース）-2〜4時間
• jenkins（パッケージの構築）-リポジトリごとに1〜32時間（リポジトリと既に生成されているものの数に依存します-最初のものは持ち上げるのが難しく、さらに簡単です）
• 独自のリポジトリ-2〜4時間
• wiki-1〜16時間
• ブログシステム-2〜4時間
• タスクトラッカー-1-8時間
• プログラマの略-???
• テストスタンド-???
• テスト実行セットアップ（可用性に応じて）-1-2時間
• zuul-2-16時間
• jabberサーバー-1〜4時間
• メールサーバー-0.5〜12時間（サイズと役割による）
• ニュースレター-1〜3時間
• 構成管理システム-各ポイントからx2（パッケージアセンブリを除く）
• バックアップ-各サービスにつき約1時間
• すべて+1時間のDNS

これは純粋に洗練された時間であることに注意してください（それほど多くはありません）。 さらに、多くのことはすべての従業員の関与を必要とします。つまり、それらを別の特別な人に割り当てることはできません。つまり、通常の作業に加えて実装時間が不鮮明になります。



作業時間の約30％が独自のインフラストラクチャに割り当てられる場合（これは非常に多く）、ゼロからの実装には3か月から1年かかります。 これは一定の熱意であり、一時停止がある場合、時間が増加します（ダウンタイムに比例して、周囲のすべてが変化するため、一時停止後は何度もやり直す必要があります）。 休暇/病気休暇/緊急事態を考慮して、同じ天井から再び給料を取り、私たちは仕事のためだけに、鉄、電気、ライセンスの費用なしで、約100万ルーブルを取得します（図は「白人」の税金と手数料の費用を考慮しています）。



護衛の価格について。 構成管理システムへの投資、バックアップ、徹底的な実装に大きく依存しています。 優れたシステムでは、1か月あたり数時間以内に加えて、新しいプロジェクト、構成、既存のものの変更などの個別のコストを追加する必要があります。



何台のサーバーが必要ですか？ 答えはテスト構成に大きく依存します。テスト構成が小さなLAMPサーバー（すべてに1GBのメモリ）であると仮定した場合、2〜5台のサーバー（〜200-300 tr。それぞれ）に加えて、個別のバックアップサーバー。 ああ、はい、構成作業のリストに追加しますが、この仮想マシンとバーチャライザーのスタックは維持します。



もちろん、これはすべて、タワークレーンオペレーター（600万ルーブル）または高精度のロボットフライス盤および掘削機の1つの作業場のコストと比較すると見劣りします（たとえば、パブリックドメインでは価格さえ見つけられませんでした）。

本当に必要ですか？

保存することはできますか？



できます。



さらに、致命的なことは起こりません。 ただし、一部のワークフローは長くなり、一部は退屈になり（郵便で郵便番号の変更を相互に送信する）、何人かの従業員が何かをするためにオフィスにいることを余儀なくされます（たとえば、コードの変更を調整します）、1つの病気従業員の数は、他の人の生活を大きく複雑にする可能性があります（そして、誰がここにいたのでしょうか？ コードの品質が部分的に低下するか、プログラマの速度が低下します。 いくつかの非常にクールなものは単純に利用できませんが、それらなしでは大丈夫です。 一部の従業員は生産性の低い仕事で忙しくなりますが、そのために、自分が支払われた仕事をするだけでなく、やる気を失わせることもあります。単調で、退屈で、ミスを抱えており、時々プロセスを繰り返すことは、実装の絶好の機会です上記の。 または、更新を再開します、はい。



労働効率に対するすべての設備投資と同様に、これらのシステムはすべてオプションです。 最終的に、宇宙へのロケットは、コードのレビューとテストでgitを使用せずに、ある種の試みで成功裏に打ち上げられました。

おわりに

企業はしばしばこのようなシステムを徐々に導入する道をたどり、単一の有用なコードを書かずにインフラストラクチャ全体を3か月上昇させてスタートアップを開始するのは大きな間違いです。



多くの場合、いくつかの段階で停止します。 彼らは通常、スタッフの不本意によって引き起こされます。なぜなら、彼ら（スタッフ）はシステムが取り除くべき苦痛を持っていないからです。 本当に痛みがない場合-素晴らしい、特に高度な複雑なものを節約できます。 人が「異なって」試みたことがないために「痛み」がない場合、停止は資格の欠如によってのみ引き起こされた可能性があります。



gitの無知が非識字または不明瞭なスピーチの類似物、つまりgitの使用方法を知らないプログラマーが非常に「特殊」（1C、SAP）であるか、あまりプログラマーではない場合、gerritの「無知」は非常に理解可能であり、トレーニングが必要になります。 プロセス統合のレベルが高いほど、非常に多くの従業員が単純にあまり学習したくない可能性が高くなります。 ブックキーパーとは異なり、システム管理者とプログラマーは非常に迅速に訓練されますが、「迅速に」動作しない場合、抵抗は1Cバージョンを変更することによる激怒のうめきよりもはるかに大きくなる可能性があります。 失敗した技術ソリューションの強制的な実装にinしている主要な技術者ほど悪いものはありません。



多くの場合、新しい実装は、従業員の1人の熱意、または妨害行為では隠されないが同僚/上司に明示的に表される完全に耐えられない痛みの存在下で発生します。



この記事では、生産の監視、そこからのログの構築、メトリックのダウンロード、およびその他のスマートな問題はまったく考慮されていないため、上記のテキストはバックオフィスについて説明していることに注意してください。



PSそうそう、私はほとんど忘れていました-機器のリストで-私はまだ休暇申請書を印刷するためにオフィスにプリンタが必要です。