アウトソーシングから開発まで（後編）

皆さんこんにちは、私の名前はセルゲイ・エメリャンチクです。 私は Audit-Telecom 会社の責任者であり、Veliam システムの主な開発者および作成者です。 私は友人と私がアウトソーシング会社を設立し、自分たちでソフトウェアを作成し、その後それを SaaS システム経由で全員に配布し始めた方法について記事を書くことにしました。 私がこれが可能であるとはっきりと信じていなかった方法について。 この記事にはストーリーだけでなく、Veliam 製品がどのように作成されたかについての技術的な詳細も含まれます。 いくつかのソースコードが含まれています。 どのような間違いがあったのか、どのように修正したかについては後ほど説明します。 このような記事を掲載するかどうかは疑問がありました。 しかし、記事を公開せずに、もし公開していたらどうなっていたかを考えるよりも、実行してフィードバックを得て改善したほうが良いと考えました。

背景

私はある会社でIT社員として働いていました。 この会社は非常に大規模で、広範なネットワーク構造を持っていました。 私の職務上の責任については言及しません。ただ、彼らには何も開発が含まれていなかったとだけ言っておきます。

モニタリングはありましたが、純粋に学術的な興味から、私自身の最も単純なものを書いてみたかったのです。 アイデアは次のとおりです。これを Web 上に置き、クライアントをインストールせずに簡単にアクセスして、Wi-Fi 経由のモバイル デバイスを含む任意のデバイスからネットワークで何が起こっているかを確認できるようにしたいと考えました。早く内容を知りたかった 部屋の設備が「モッピー」になっているため... このような問題に対する応答時間には非常に厳しい要件がありました。 その結果、JPEG の背景にネットワーク図を描いたシンプルな Web ページを作成し、この写真から IP アドレスを持つデバイス自体を切り出し、その上に動的コンテンツを表示するという計画が私の頭の中で生まれました。緑色または赤色で点滅する IP アドレスの形式で、必要な座標の画像を表示します。 タスクが設定されました。始めましょう。

以前は、Delphi、PHP、JS、そしてごく表面的には C++ でプログラミングしていました。 私はネットワークがどのように機能するかをよく知っています。 VLAN、ルーティング (OSPF、EIGRP、BGP)、NAT。 私自身が原始的な監視プロトタイプを作成するにはこれで十分でした。

私は自分の考えをPHPで書きました。ApacheサーバーとPHPは Windows なぜなら Linux 当時の私にとってそれは理解しがたい、非常に難しいことだったが、後になって分かったように、私は非常に間違っていたし、多くの点で Linux はるかにシンプル Windowsしかしそれは別の話題であり、この話題に関してどれほど多くの論争があるかは周知の通りです。タスクスケジューラ Windows 私は短い間隔（正確には覚えていませんが、3秒に1回程度）でPHPスクリプトを実行し、簡単なpingで全てのオブジェクトをポーリングして、その状態をファイルに保存しました。

system(“ping -n 3 -w 100 {$ip_address}“); 

はい、はい、その時点ではデータベースの操作も私にとってはマスターできていませんでした。 プロセスを並列化できるとは知りませんでしたが、すべてのネットワーク ノードを通過するのに時間がかかりました。 これはあるスレッドで起こりました。 特に、いくつかのノードが利用できない場合に問題が発生しました。 それぞれのスクリプトは 300 ミリ秒遅延しました。 クライアント側には、数秒間隔で、Ajax リクエストを使用してサーバーから更新情報をダウンロードし、インターフェイスを更新する単純なループ関数がありました。 さて、ping が 3 回連続で失敗した後、監視機能のある Web ページがコンピュータ上で開いていると、陽気な曲が再生されました。

すべてがうまくいったとき、私はその結果に非常にインスピレーションを受け、（自分の知識と能力のおかげで）さらにその結果に追加できると考えました。 しかし、私は XNUMX 万ものチャートを備えたシステムがずっと好きではありませんでした。当時も、そして今でもそう思っていますが、これはほとんどの場合不要です。 自分の仕事に本当に役立つものだけをそこに入れたかったんです。 この原則は、今日に至るまで Veliam の開発の基礎となっています。 さらに、監視をオープンにし続ける必要がなく、問題が発生したときにそれを把握でき、問題が発生したときにページを開いて、この問題のあるネットワーク ノードがどこにあるか、次に何をすべきかを確認できれば、非常に素晴らしいだろうということに気づきました。 。 どういうわけか、当時私は電子メールを読まなかっただけで、単に電子メールを使用しませんでした。 インターネットで、GET または POST リクエストを送信できる SMS ゲートウェイがあることを知りました。そうすれば、私が書いたテキストを含む SMS が携帯電話に送信されます。 本当にこれが欲しかったのだとすぐに気づきました。 そして私はドキュメントを勉強し始めました。 しばらくして成功し、今度は携帯電話にネットワークの問題に関する「落下物」という名前のSMSが届きました。 このシステムは原始的でしたが、私自身が作成したもので、開発の動機となった最も重要な点は、それが私の仕事に本当に役立つアプリケーション プログラムだったことです。

そして、職場でインターネット チャネルの XNUMX つがダウンした日が来ました。私の監視ではそれがわかりませんでした。 Google DNS は依然として完全に ping を実行しているためです。 通信チャネルが生きていることを監視する方法を考えてみましょう。 これを行う方法についてはさまざまなアイデアがありました。 すべての機器にアクセスできませんでした。 どのチャンネルがライブであるかを理解する方法を考え出す必要がありましたが、ネットワーク機器自体でそれを表示することはできませんでした。 そこで同僚は、インターネットへのアクセスに現在どの通信チャネルが使用されているかによって、パブリック サーバーへのルート トレースが異なる可能性があるというアイデアを思いつきました。 調べてみたらその通りでした。 トレースするとさまざまなルートがありました。

system(“tracert -d -w 500 8.8.8.8”);

そこで、別のスクリプトが登場しました。つまり、何らかの理由で同じスクリプトの最後にトレースが追加され、ネットワーク上のすべてのデバイスに ping が送信されました。 結局のところ、これは同じスレッドで実行される別の長いプロセスであり、スクリプト全体の作業が遅くなります。 しかし、それはそれほど明白ではありませんでした。 しかし、いずれにせよ、彼は自分の仕事を果たし、各チャネルに対してどのような種類のトレースを行うべきかをコードで厳密に規定しました。 このようにして、ネットワーク デバイス (ルーター、スイッチ、Wi-Fi など) と外部との通信チャネルを既に監視 (メトリクスの収集がなく、ping を送信するだけであるため、大声で言われました) したシステムが動作し始めました。 。 SMS メッセージは定期的に届き、図には問題の場所が常に明確に示されていました。

さらに、日常の仕事では十字路をやらなければなりませんでした。 そして、どのインターフェイスを使用するかを確認するために毎回 Cisco スイッチに行くのにうんざりしました。 監視中のオブジェクトをクリックして、そのインターフェイスのリストと説明が表示されたら、どんなに素晴らしいでしょう。 そうすれば時間の節約になります。 さらに、このスキームでは、アカウントやコマンドを入力するために Putty や SecureCRT を実行する必要はありません。 私はモニタリングをクリックして、必要なものを確認して、自分の仕事に取り掛かりました。 私はスイッチを操作する方法を探し始めました。 すぐに 2 つのオプションが見つかりました。SNMP または SSH 経由でスイッチにログインし、必要なコマンドを入力して結果を解析する方法です。 SNMP の実装が複雑だったので、結果を得るのが待ちきれなかったので SNMP を無視しました。 SNMP を使用する場合は、MIB を長時間にわたって調査し、このデータに基づいてインターフェイスに関するデータを生成する必要があります。 CISCOには素晴らしいチームがあります

show interface status

横断に必要なものを正確に示しています。 このコマンドの出力を見たいだけなのに、なぜわざわざ SNMP を使う必要があるのか​​と思いました。 しばらくして、私はこの機会に気づきました。 Web ページ上のオブジェクトをクリックしました。 AJAX クライアントがサーバーに接続することでイベントがトリガーされ、必要なスイッチに SSH 経由で接続されました (資格情報はコードにハードコードされており、コードを改良していくつかの別個のメニューを作成する必要はありませんでした)インターフェイスからアカウントを変更することは可能です。結果が必要でしたので、すぐに）上記のコマンドをそこに入力し、ブラウザに送り返しました。 そこで、マウスを XNUMX 回クリックするだけでインターフェイスに関する情報が表示されるようになりました。 これは、特にこの情報をさまざまなスイッチで同時に表示する必要がある場合に、非常に便利でした。

トレースベースのチャネル監視は、結局最良のアイデアとは言えませんでした。 時々、ネットワーク上で作業が実行され、トレースが変化する可能性があり、監視がチャネルに問題があると私に叫び始めました。 しかし、分析に多くの時間を費やした後、すべてのチャネルが機能しており、監視が私を欺いていたことに気づきました。 その結果、チャネル形成スイッチを管理する同僚に、近隣の可視性ステータスが変化したときに syslog を送信するように依頼しました。 したがって、トレースよりもはるかに簡単、高速、かつ正確です。 隣人喪失のようなイベントが到着し、すぐにチャンネルダウンの通知を出します。

さらに、オブジェクトをクリックするとさらにいくつかのコマンドが表示され、いくつかのメトリクスを収集するために SNMP が追加されました。基本的にはそれだけです。 このシステムはそれ以上発展することはありませんでした。 必要なものはすべて揃っていて、良いツールでした。 おそらく多くの読者は、これらの問題を解決するためのソフトウェアがインターネット上にすでにたくさんあると言うでしょう。 しかし実際には、当時私はそのような無料の製品をグーグルで検索することはなく、プログラミング スキルを向上させたかったのです。これを推進するには、実際のアプリケーションの問題以上に優れた方法はありません。 この時点で、最初のバージョンのモニタリングが完了し、変更は行われなくなりました。

Audit-Telecom という会社の設立

時が経つにつれて、幸いにも仕事のスケジュールの都合で他の会社でパートタイムで働くようになりました。 さまざまな会社で働くと、さまざまな分野のスキルが非常に早く成長し、視野が広がります。 よく言われるように、あなたはスウェーデン人であり、死神であり、トランペット奏者であるという会社があります。 それは難しい一方で、怠け者でなければジェネラリストになり、関連分野がどのように機能するかを知っているため、問題をより迅速かつ効率的に解決できるようになります。

私の友人のパベル (同じく IT スペシャリスト) は、私に自分のビジネスを始めるよう常に勧めようとしていました。 彼らが行っていることのさまざまなバリエーションを含む無数のアイデアがありました。 これについては何年も議論されてきました。 そして結局のところ、私は懐疑論者であり、パベルは夢想家なので、何も起こらなかったはずです。 彼がアイデアを提案するたびに、私はいつもそれを信じられず、参加することを拒否しました。 しかし、私たちは本当に自分たちのビジネスを開きたかったのです。

最終的に、私たちはお互いに合った選択肢を見つけ、やり方を知っていることを実行することができました。 2016年、私たちは企業のIT課題解決を支援するIT企業の設立を決意しました。 これは、IT システム (1C、ターミナル サーバー、メール サーバーなど) の導入、そのメンテナンス、ユーザー向けの従来のヘルプデスク、およびネットワーク管理です。

正直に言うと、会社を作った時点では99,9%くらい信じていませんでした。 しかし、どういうわけかパベルは私に挑戦させることができ、将来を見据えて、彼は正しかったことが判明しました。 パベルと私は、それぞれ300万ルーブルを注ぎ込み、新しいLLC「Audit-Telecom」を登録し、小さなオフィスを借り、おそらくほとんどの経験の浅い初心者のビジネスマンと同じように、クールな名刺を作り、顧客を探し始めました。 顧客を見つけることはまったく別の話です。 興味があれば、企業ブログの一部として別の記事を書くかもしれません。 勧誘電話、チラシなどこれでは結果は得られませんでした。 ビジネスに関する多くの話を今読んでいると、何らかの形で多くのことが運に左右されます。 我々は幸運だった。 そして会社設立から文字通り数週間後、兄のウラジミールが私たちに声をかけてきて、彼が私たちに最初の顧客を連れてきました。 クライアントとの仕事の詳細については説明しません。それがこの記事の内容ではありません。ただ、監査に行って重要な領域を特定しましたが、その領域を改善するかどうかの決定が行われる間に問題が発生したとだけ言っておきます。アウトソーサーとして継続的に協力してください。 この後、すぐに前向きな決定が下されました。

その後、主に友人の口コミで他のサービス会社も登場し始めました。 ヘルプデスクは XNUMX つのシステム内にありました。 ネットワーク機器とサーバーへの接続は異なります、というよりむしろ異なります。 ショートカットを保存している人もいれば、RDP アドレス帳を使用している人もいます。 モニタリングは別の別のシステムです。 チームが異なるシステムで作業するのは非常に不便です。 重要な情報が見失われます。 たとえば、クライアントのターミナル サーバーが使用できなくなりました。 このクライアントのユーザーからの申請は直ちに受け付けられます。 サポート スペシャリストがリクエストを開始します (リクエストは電話で受信されました)。 インシデントとリクエストが XNUMX つのシステムに登録されている場合、サポート スペシャリストはユーザーの問題を即座に認識してそれを伝え、同時に必要なオブジェクトに接続して状況を解決します。 全員が戦術的な状況を認識しており、調和して取り組んでいます。 これらすべてを組み合わせたシステムはまだ見つかっていません。 私たち自身の製品を作る時期が来たことが明らかになりました。

監視システムの継続的な作業

以前に作成されたシステムが現在のタスクにはまったく適していないことは明らかでした。 機能面でも品質面でも問題ありません。 そして、システムを一から書くことにしました。 グラフィック的にはまったく違って見えるはずです。 適切なクライアントに対して適切なオブジェクトを迅速かつ便利に開くことができるように、階層システムである必要がありました。 最初のバージョンのようなスキームは、現在のケースではまったく正当化されません。 クライアントはさまざまであり、機器がどの敷地内に設置されているかはまったく問題ではありませんでした。 これはすでにドキュメントに転送されています。

したがって、タスクは次のとおりです。

1. 階層構造;
2. クライアントの敷地内に仮想マシンの形で配置できるある種のサーバー部分。必要なメトリクスを収集して中央サーバーに送信し、中央サーバーがこれらすべてを要約して表示します。
3. アラート。 見逃せないもの、なぜなら... 当時は座ってただモニターを見ることは不可能でした。
4. アプリケーションシステム。 サーバーやネットワーク機器だけでなく、ワークステーションもサービスするクライアントが現れ始めました。
5. システムからサーバーや機器に迅速に接続する機能。

タスクが設定され、私たちは執筆を開始しました。その過程で、クライアントからのリクエストを処理しました。その時点で、私たちはすでに4人になっていました。私たちは中央サーバーとクライアントインストール用サーバーの両方の部分を同時に書き始めました。この時点で、 Linux それはもはや私たちにとって馴染みのないものではなく、クライアントにインストールされる仮想マシンは Debianインストーラーは用意しません。単一の仮想マシン上にサーバーサイドプロジェクトを作成し、それを必要なクライアントにクローンするだけです。しかし、これもまた間違いでした。後になって、この構成には更新メカニズムが全くないことが明らかになったのです。そのため、新しい機能を追加すると、それをすべてのクライアントサーバーに配布するのが非常に面倒な作業になってしまいました。しかし、その点については後ほど詳しく説明します。

最初のプロトタイプを作りました。 彼は、必要なクライアント ネットワーク デバイスとサーバーに ping を送信し、このデータを中央サーバーに送信することができました。 そして彼は、このデータを中央サーバー上で一括更新しました。 ここでは、何がどのようにして成功したかだけでなく、どのような素人的な間違いがあり、後でどのようにしてその代償を払わなければならなかったのかについても書きます。 したがって、オブジェクトのツリー全体が、シリアル化されたオブジェクトの形式で XNUMX ​​つの単一ファイルに保存されました。 いくつかのクライアントをシステムに接続している間、すべてが多かれ少なかれ正常でしたが、完全に理解できないアーティファクトがいくつか発生することがありました。 しかし、十数台のサーバーをシステムに接続すると、奇跡が起こり始めました。 場合によっては、何らかの未知の理由で、システム内のすべてのオブジェクトが単に消えてしまうこともあります。 ここで、クライアントのサーバーが POST リクエストを介して数秒ごとに中央サーバーにデータを送信していたことに注意することが重要です。 注意深い読者と経験豊富なプログラマは、シリアル化されたオブジェクトが格納されているファイルそのものに対して、異なるスレッドから同時に複数アクセスするという問題があることをすでに推測していました。 そしてちょうどこれが起こっているとき、物体の消失という奇跡が起こりました。 ファイルが空になっただけです。 しかし、これらすべてはすぐには発見されず、複数のサーバーでの運用中にのみ発見されました。 この間、ポート スキャン機能が追加されました (サーバーは、デバイスの可用性に関する情報だけでなく、デバイス上で開いているポートに関する情報も中央に送信しました)。 これは、次のコマンドを呼び出すことで実行されました。

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

結果は不正確であることが多く、スキャンが完了するまでに長い時間がかかりました。 ping のことをすっかり忘れていましたが、fping 経由で実行されました。

system("fping -r 3 -t 100 {$this->ip}");

これも並列化されていなかったため、プロセスに非常に時間がかかりました。 その後、検証に必要な IP アドレスのリスト全体が一度に fping に送信され、応答した人の既製のリストを受け取りました。 私たちと違って、fping はプロセスを並列化することができました。

もう XNUMX つの一般的な日常業務は、WEB 経由でいくつかのサービスをセットアップすることでした。 たとえば、MS Exchange の ECP です。 基本的にはただのリンクです。 そして、特定のクライアントの ECP にアクセスする方法についてドキュメントやブックマークのどこかを参照する必要がないように、そのようなリンクをシステムに直接追加できる必要があると判断しました。 これが、システムのリソース リンクの概念がどのようにして登場したかであり、その機能は今日まで利用可能であり、ほとんど変わっていません。

Veliam でのリソース リンクの仕組み

リモート接続

現在のバージョンの Veliam で動作すると次のようになります。

タスクの 2 つは、サーバーに迅速かつ便利に接続することでしたが、そのサーバーはすでに多数 (XNUMX 以上) 存在しており、事前に保存された何百万もの RDP ショートカットを並べ替えるのは非常に不便でした。 工具が必要でした。 このような RDP 接続用のアドレス帳のようなソフトウェアがインターネット上にありますが、監視システムと統合されておらず、アカウントを保存することはできません。 XNUMX 日に何十回も異なるサーバーに接続する場合、毎回異なるクライアントのアカウントを入力するのはまさに地獄です。 SSH を使用すると状況は少し改善され、そのような接続をフォルダーに整理し、そこからアカウントを記憶できる優れたソフトウェアがたくさんあります。 しかし、問題が XNUMX つあります。 XNUMX つ目は、RDP および SSH 接続用のプログラムが XNUMX つも見つからなかったことです。 XNUMX つ目は、ある時点でコンピューターの前にいないときにすぐに接続する必要がある場合、またはシステムを再インストールしたばかりの場合、このクライアントのアカウントを確認するためにドキュメントにアクセスする必要があることです。 不便ですし、時間の無駄です。

クライアント サーバーに必要な階層構造は、社内製品ですでに利用可能でした。 そこで必要な機器にクイック接続を接続する方法を考え出す必要がありました。 まず、少なくともネットワーク内で。

システム内のクライアントはコンピュータのローカルリソースにアクセスできないブラウザであったため、必要なアプリケーションをコマンドで起動するだけで済むように、すべてを「Windows カスタム URL スキーム」このようにして、システム用の「プラグイン」が現れました。これは単に Putty と Remote Desktop Plus を含み、インストール時に URI スキームを登録するだけです。 Windowsさて、RDP または SSH を介してオブジェクトに接続したいときはいつでも、システムでそのアクションをクリックすると、カスタム URI が起動します。標準の mstsc.exe は、 Windows あるいは、PuTTYというソフトウェアもあります。これは「プラグイン」の一部として含まれていました。「プラグイン」という言葉を引用符で囲んだのは、これは従来の意味でのブラウザプラグインではないからです。

それは少なくとも何かしらの役に立った。便利なアドレス帳だ。そしてPuttyの場合は、すべて問題なかった。接続IPアドレス、ログイン名、パスワードを入力パラメータとして指定できた。つまり、 Linux すでに、パスワードを入力せずにワンクリックでネットワーク上のサーバーに接続できていました。しかし、RDP はそれほど単純ではありません。標準の mstsc に資格情報をパラメータとして渡すことはできません。そこで、Remote Desktop Plus が救世主となりました。Remote Desktop Plus のおかげで、これが可能になりました。その後は、Remote Desktop Plus なしでも問題なく運用できていますが、長い間、システム内で頼りになるアシスタントでした。HTTP(S) サイトは簡単です。そのようなオブジェクトはブラウザで開くだけで済みます。便利で実用的です。しかし、これは内部ネットワークでのみ恩恵でした。

ほとんどの問題はオフィスからリモートで解決していたため、最も簡単な方法はクライアントにVPNを設定することでした。そうすれば、私たちのシステムからクライアントに接続できるようになりました。しかし、それでもまだ少し不便でした。クライアントごとに、各コンピュータに大量のパスワードを保存しておく必要がありました。 VPN 接続設定は、接続する前に必ず対応するVPNを有効にする必要がありました。この解決策をかなり長い間使っていました。しかし、クライアント数とVPNの数が増えていくにつれ、この作業が煩わしくなり始め、何らかの対策が必要になりました。特にシステムを再インストールした後、新しいWindowsプロファイルに数十ものVPN接続を再入力しなければならなかった時は、本当に涙が出るほど辛かったです。「もううんざりだ」と思い、どうにかできないかと考え始めました。

たまたま、すべてのクライアントがルーターとして有名な会社Mikrotikのデバイスを持っていました。 これらは非常に機能的で、ほぼすべてのタスクを実行するのに便利です。 欠点は「乗っ取られる」ことです。 私たちは外部からのアクセスをすべて遮断することでこの問題を解決しました。 しかし、クライアントの場所に行かなくても、何らかの方法でそれらにアクセスできるようにする必要がありました。 それは長い。 私たちは、そのような Mikrotik ごとにトンネルを作成し、それらを別のプールに分離しただけです。 ルーティングを行わないため、あなたのネットワークとクライアントのネットワーク、およびクライアントのネットワーク同士の接続は存在しません。

このアイデアは、システム内で必要なオブジェクトをクリックすると、すべてのクライアント Mikrotik の SSH アカウントを認識している中央監視サーバーが目的のアカウントに接続し、目的のホストへの転送ルールを作成することを保証するために生まれました。必要なポート。 ここにはいくつかのポイントがあります。 この解決策は万能ではありません。コマンド構文はすべてのルーターで異なるため、Mikrotik でのみ機能します。 また、そのような転送は何らかの方法で削除する必要があり、システムのサーバー部分は基本的に、私が RDP セッションを終了したかどうかを追跡することができませんでした。 まあ、そのような転送はクライアントにとって穴です。 でも、普遍性を追求しなかったのは… この製品は社内でのみ使用されており、一般に公開する考えはありませんでした。

それぞれの問題は独自の方法で解決されました。 ルールが作成されたとき、この転送は XNUMX つの特定の外部 IP アドレス (接続の初期化元) に対してのみ利用可能でした。 したがって、セキュリティホールは回避されました。 しかし、そのような接続のたびに、Mikrotik ルールが NAT ページに追加され、クリアされませんでした。 そして、ルールが増えれば増えるほど、ルーターのプロセッサの負荷が増えることは誰もが知っています。 そして一般的に、私はいつかミクロティクに行くと、何百もの死んだ役に立たないルールが存在することを受け入れることができませんでした。

私たちのサーバーは接続ステータスを追跡できないため、Mikrotik 自体が接続ステータスを追跡できるようにします。 そして、特定の説明を含むすべての転送ルールを常に監視し、TCP 接続に適切なルールがあるかどうかをチェックするスクリプトを作成しました。 しばらくの間接続がなかった場合は、接続がすでに完了している可能性があり、この転送は削除できます。 すべてがうまくいき、脚本もうまくいきました。

ちなみに、これは次のとおりです。

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="Removing nat rules added automaticaly by atmon_script"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

確かに、もっと美しく、より速くなどすることはできましたが、機能し、Mikrotikをロードせず、素晴らしい仕事をしました。 ついにワンクリックでクライアントのサーバーやネットワーク機器に接続できるようになりました。 VPNを開いたり、パスワードを入力したりする必要はありません。 このシステムは本当に使いやすくなりました。 サービス時間が短縮され、全員が必要なオブジェクトに接続する代わりに作業に時間を費やしました。

Mikrotikのバックアップ

すべての Mikrotik の FTP へのバックアップを構成しました。 そして全体的にはすべて順調でした。 しかし、バックアップを取得する必要がある場合は、この FTP を開いてそこで探す必要がありました。 すべてのルーターが接続されているシステムがあり、SSH 経由でデバイスと通信できます。 システム自体が毎日すべての Mikrotik からバックアップを取得するようにしたらどうだろうか、と私は思いました。 そして彼はそれを実行し始めました。 接続してバックアップを作成し、ストレージに保存しました。

Mikrotik からバックアップを取得するための PHP のスクリプト コード:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
    stream_get_contents($connection);
    ssh2_exec($connection, '/export file="atmon.rsc"');
    stream_get_contents($connection);
    sleep(40); // Waiting bakup makes

    $sftp = ssh2_sftp($connection);

    // Download backup file
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    // Download RSC file
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

バックアップは、バイナリ構成とテキスト構成の XNUMX つの形式で取得されます。 バイナリは必要な構成を迅速に復元するのに役立ち、テキスト バイナリを使用すると、機器の強制交換が発生してバイナリをアップロードできない場合に何を行う必要があるかを理解できます。 その結果、システムに別の便利な機能が追加されました。 さらに、新しい Mikrotik を追加する場合、何も設定する必要はなく、オブジェクトをシステムに追加し、SSH 経由でアカウントを設定するだけで済みました。 その後、システム自体がバックアップを作成します。 SaaS Veliam の現在のバージョンにはまだこの機能がありませんが、間もなく移植される予定です。

内部システムのスクリーンショット

通常のデータベースストレージへの移行

アーティファクトが現れることは上ですでに書きました。 システム内のオブジェクトのリスト全体が単に消えてしまうこともあれば、オブジェクトの編集時に情報が保存されず、オブジェクトの名前を XNUMX 回変更する必要があることもありました。 これには皆がひどくイライラしました。 オブジェクトの消失はほとんど発生せず、このファイルを復元することで簡単に復元されましたが、オブジェクトの編集時に失敗することが非常に頻繁に発生しました。 おそらく、最初はデータベースを介してこれを実行しませんでした。これは、すべての接続を含むツリーをフラット テーブルに保持する方法が私の頭に合わなかったためです。 平坦ですが、ツリーは階層的です。 しかし、複数のアクセス、そしてその後 (システムがより複雑になるにつれて) トランザクションに適したソリューションは、DBMS です。 おそらくこの問題に遭遇したのは私が初めてではありません。 グーグル検索を始めました。 すべては私より前にすでに発明されており、平らなテーブルからツリーを構築するアルゴリズムがいくつかあることが判明しました。 それぞれを確認した後、そのうちの XNUMX つを実装しました。 しかし、これはすでにシステムの新しいバージョンでした。なぜなら... 実はこのため、かなり書き直さなければなりませんでした。 結果は当然で、システムのランダムな動作の問題は解消されました。 ソフトウェア開発の分野では、これらのエラーは非常に素人っぽい (シングルスレッドのスクリプト、異なるスレッドから同時に複数回アクセスされた情報をファイルに保存するなど) と言う人もいるかもしれません。 おそらくこれは本当かもしれませんが、私の本業は管理であり、プログラミングは私の心の副業であり、プログラマーのチームで働いた経験がなかったため、そのような基本的なことは先輩からすぐに提案されていたでしょう。同志たち。 したがって、これらの凹凸はすべて自分で埋めましたが、内容は非常によく学びました。 また、私の仕事には、クライアントとのミーティング、会社の宣伝を目的とした活動、社内の管理上の問題などが含まれます。 しかし、何らかの形で、すでに存在しているものは需要があったのです。 私も彼らも毎日の仕事でこの製品を使用しました。 率直に言って、時間を無駄にして失敗したアイデアや解決策もありましたが、最終的にはこれが機能するツールではないことが明らかになり、誰も使用しなかったため、Veliam に導入されることはありませんでした。

ヘルプデスク - ヘルプデスク

ヘルプデスクがどのように設立されたかについて言及することは間違いではありません。 これはまったく別の話です、なぜなら... Veliam では、これはすでに 3 番目の完全な新しいバージョンであり、これまでのすべてのバージョンとは異なります。 現在では、不要な付加機能のない直感的なシンプルなシステムとなっており、ドメインと統合する機能や、電子メールのリンクを使用してどこからでも同じユーザー プロファイルにアクセスできる機能が備わっています。 そして最も重要なことは、VPN やポート転送を使用せずに、どこからでも (自宅またはオフィス内) アプリケーションから直接 VNC 経由で申請者に接続できることです。 私たちがどのようにしてこれに至ったのか、以前に何が起こったのか、そしてどのような恐ろしい決断が下されたのかをお話しします。

私たちはよく知られている TeamViewer を通じてユーザーとつながりました。 当社がサービスを提供するユーザーが使用するすべてのコンピュータにはテレビがインストールされています。 私たちが最初に間違って、その後削除したのは、各 HD クライアントをハードウェアにリンクすることでした。 ユーザーはリクエストを残すためにどのようにして HD システムにログインしましたか? テレビに加えて、誰もが自分のコンピュータに Lazarus で書かれた特別なユーティリティをインストールしていました (ここにいる多くの人は目を丸くして、それが何なのかを Google で調べるかもしれませんが、私が知っている中で最高のコンパイル言語は Delphi で、Lazarus はほとんど同じものですが、無料のみです）。 一般に、ユーザーはこのユーティリティを起動する特別なバッチ ファイルを起動し、これによりシステムの HWID が読み取られ、その後ブラウザが起動されて認証が行われます。 なぜこれが行われたのでしょうか? 企業によっては、サービス利用者数を個別にカウントし、人数に応じて月ごとのサービス料金を設定しているところもあります。 それは理解できますが、なぜそれがハードウェアに関連付けられているのでしょうか? それはとてもシンプルで、帰宅して自宅のラップトップから「ここのすべてを美しくしてください」というスタイルでリクエストをした人もいました。 このユーティリティは、システム HWID の読み取りに加えて、現在の Teamviewer ID をレジストリから取得し、それを私たちに送信しました。 Teamviewer には統合用の API があります。 そして私たちはこの統合を行いました。 しかし、落とし穴が XNUMX つありました。 ユーザーがこのセッションを明示的に開始しない場合、これらの API を介してユーザーのコンピュータに接続することは不可能であり、接続を試行した後も「確認」をクリックする必要があります。 その時点では、ユーザーの要求がなければ誰も接続すべきではない、というのが私たちにとって論理的であるように思えました。そのユーザーはコンピューターの前にいるので、セッションを開始し、リモート接続要求に肯定的に応答します。 すべてが間違っていたことが判明した。 申請者はセッションの開始を押すのを忘れたため、電話での会話でそのことを伝えなければなりませんでした。 これは時間を無駄にし、プロセスの両側でストレスを感じました。 さらに、人がリクエストを残したものの、昼食のために出発するときにのみ接続が許可されるというような瞬間はまったく珍しいことではありません。 問題は重大ではなく、作業プロセスが中断されることを望んでいないからです。 したがって、接続を許可するためにボタンを押すことはありません。 これは、ヘルプデスクにログインするときに追加機能がどのように表示されるか、つまり Teamviwer の ID を読み取る方法です。 Teamviwer のインストール時に使用された永久パスワードはわかっていました。 より正確に言えば、それはインストーラーとシステムに組み込まれているため、システムだけがそれを知っていました。 したがって、アプリケーションからクリックするだけで何も待つ必要のない接続ボタンがあったのですが、すぐにTeamviewerが開いて接続が行われました。 その結果、考えられる接続方法は XNUMX 種類ありました。 公式の Teamviewer API と自作の API を使用します。 驚いたことに、最初のバージョンは、特別な場合とユーザー自身がゴーサインを出した場合にのみ使用するようにという指示があったにもかかわらず、彼らはすぐに使用を中止しました。 それでも、今は私に安全を与えてください。 しかし、申請者はこれを必要としていないことが判明しました。 確認ボタンなしで接続してもまったく問題ありません。 このような状況であったため、API 接続機能は不要として削除されました。

マルチスレッドへの移行 Linux

あらかじめ決められたポートのリストをオープンにし、ネットワーク オブジェクトを単純に ping するためのネットワーク スキャナの通過を高速化するという問題は、長い間生じ始めていました。 もちろん、ここで最初に思い浮かぶ解決策はマルチスレッドです。 ping に費やされる主な時間はパケットが返されるのを待つことであり、前のパケットが返されるまで次の ping を開始できないため、20 台以上のサーバーとネットワーク機器を備えている企業であっても、この動作はすでに非常に遅くなります。 重要なのは、XNUMX つのパッケージが消える可能性がありますが、それをすぐにシステム管理者に通知しないことです。 彼はそのようなスパムの受け入れをすぐにやめるでしょう。 これは、アクセス不能であると結論付ける前に、各オブジェクトに複数回 ping を実行する必要があることを意味します。 あまり詳しく説明しませんが、並列化する必要があります。これを行わないと、システム管理者は監視システムからではなくクライアントから問題を知ることになる可能性が高いためです。

PHP 自体は、そのままではマルチスレッドをサポートしません。 マルチプロセッシングが可能で、フォークすることができます。 しかし、実際には、ポーリング メカニズムはすでに作成されており、データベースから必要なすべてのノードを一度カウントし、すべてを一度に ping し、各ノードからの応答を待ち、その後すぐに書き込むようにしたいと考えていました。データ。 これにより、読み取りリクエストの数が節約されます。 マルチスレッドはこのアイデアに完全に適合します。 PHP には、実際のマルチスレッドを実行できる PThreads モジュールがあります。これを PHP 7.2 で設定するにはかなりの手間がかかりましたが、完了しました。 ポート スキャンと ping が高速になりました。 そして、たとえば以前は 15 周あたり 2 秒かかっていたこのプロセスに、XNUMX 秒かかるようになりました。 良い結果でした。

新しい会社の迅速な監査

さまざまなメトリクスやハードウェア特性を収集する機能はどのようにして生まれたのでしょうか? それは簡単です。 場合によっては、単に現在の IT インフラストラクチャを監査するよう命じられることもあります。 新しいクライアントの監査を迅速化するためにも、同じことが必要です。 中規模または大企業に来て、彼らが何を持っているかをすぐに把握できるものが必要でした。 私の意見では、内部ネットワーク上の ping をブロックするのは、自分の生活を複雑にしたい人だけであり、私たちの経験ではそのような人はほとんどいません。 でも、そういう人もいるのです。 したがって、単純な ping でネットワークをすばやくスキャンしてデバイスの存在を確認できます。 次に、それらを追加し、興味のある開いているポートをスキャンします。 実際、この機能はすでに存在しており、中央サーバーからスレーブサーバーにコマンドを追加するだけで、指定されたネットワークをスキャンして、見つかったすべてのネットワークをリストに追加することができました。 言い忘れていましたが、構成済みのシステム (スレーブ監視サーバー) を備えた既製のイメージがすでにあり、監査中にクライアントから簡単にロールアウトしてクラウドに接続できると想定していました。

しかし、監査結果には通常、さまざまな情報が含まれており、その1つはネットワーク上にどのようなデバイスがあるかということです。私たちが主に関心を持っていたのは Windows サーバーとワークステーション Windows ドメインの一部として。中規模および大規模企業では、ドメインがないことはおそらく例外であり、一般的ではありません。同じ意味で言えば、私の考えでは、中規模企業とは従業員100人以上の企業です。私たちは、すべてのWindowsマシンとサーバーからデータを収集する方法を考案する必要がありました。各マシンとサーバーにソフトウェアをインストールすることなく、IPアドレスとドメイン管理者アカウントを把握する必要がありました。そこでWMIインターフェースが役立ちました。 Windows マネジメント・インストゥルメンテーション（WMI）とは、文字通りマネジメント・インストゥルメンテーションを意味します。 WindowsWMIは、プラットフォームの制御下にあるコンピュータインフラストラクチャのさまざまな部分を一元的に管理および監視するための基本技術の1つです。 Windowswikiから引用。その後、wmic（WMIクライアント）をビルドするために再びいじくり回す必要がありました。 Debianすべて準備が整ったら、あとはwmicを使って必要なノードにクエリを実行して必要な情報を取得するだけです。WMIを使えば、 Windows コンピュータはほぼあらゆる情報を取得でき、さらに、それを通してコンピュータを制御することもできます。たとえば、再起動を指示することもできます。このようにして、コンピュータに関する情報が収集されます。 Windows システム内のステーションとサーバーに関する情報。これに加えて、現在のシステム負荷指標に関する最新情報も提供されました。ハードウェア情報はそれほど頻繁には要求しませんが、これらの情報はより頻繁に要求します。その後、監査作業は少し楽しくなりました。

ソフトウェア配布の決定

私たち自身もこのシステムを毎日使用しており、すべての技術従業員がいつでも利用できるようにしています。 そして、私たちがすでに持っているものを他の人と共有できると考えました。 システムはまだ配布する準備ができていませんでした。 ローカル バージョンを SaaS に変えるためには、多くの部分をやり直す必要がありました。 これには、システムのさまざまな技術的側面 (リモート接続、サポート サービス) の変更、ライセンス付与のためのモジュールの分析、顧客データベースのシャーディング、各サービスのスケーリング、およびすべての部分の自動更新システムの開発が含まれます。 ただし、これは記事の第 XNUMX 部になります。

更新

第二部

出所： habr.com