從外包到開發(第二部分)

大家好,我的名字是謝爾蓋‧艾梅利揚奇克。 我是 Audit-Telecom 公司的負責人,Veliam 系統的主要開發者和作者。 我決定寫一篇文章,講述我和朋友如何創建一家外包公司,為自己編寫軟體,然後開始透過 SaaS 系統分發給每個人。 關於我如何斷然不相信這是可能的。 這篇文章不僅包含一個故事,還包含有關 Veliam 產品如何創建的技術細節。 包括一些原始碼。 我會告訴你我們犯了哪些錯誤以及後來我們如何修正這些錯誤。 有人質疑是否發表這樣的文章。 但我認為這樣做,獲得反饋並改進,比不發表文章並思考如果......會發生什麼更好。

我曾在一家公司擔任 IT 員工。 該公司規模相當大,網路結構廣泛。 我不會詳述我的工作職責,我只會說它們絕對不包括任何開發。

我們有監控,但純粹出於學術興趣,我想嘗試寫自己最簡單的一個。 我的想法是這樣的:我希望它能在網路上,這樣我就可以輕鬆地進入而無需安裝任何客戶端,並從任何裝置(包括透過Wi-Fi 的行動裝置)查看網路發生了什麼情況,而且我也真的想要快速了解房間裡的設備變得“悶悶不樂”,因為... 對此類問題的回應時間有非常嚴格的要求。 於是,我的腦海中誕生了一個計劃,寫一個簡單的網頁,上面有一張jpeg背景和一張網絡圖,把圖中的設備本身及其IP地址剪下來,並在上面顯示動態內容。以綠色或閃爍紅色IP 位址形式顯示所需座標中的圖片。 任務已定,讓我們開始吧。

先前,我使用 Delphi、PHP、JS 和非常膚淺的 C++ 進行程式設計。 我非常了解網路是如何運作的。 VLAN、路由(OSPF、EIGRP、BGP)、NAT。 這足以讓我自己寫一個原始的監視原型。

我用 PHP 寫了我的計畫。 Apache 和 PHP 伺服器位於 Windows 上,因為... 當時 Linux 對我來說是一個難以理解且非常複雜的東西,後來證明,我錯了,在很多地方 Linux 比 Windows 簡單得多,但這是一個單獨的話題,我們都知道上面有多少個 holivars。這個話題。 Windows 任務排程器以很小的間隔(我記不太清了,但大約每三秒一次)拉取一個 PHP 腳本,該腳本使用普通 ping 輪詢所有物件並將狀態保存到檔案中。

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

是的,是的,當時我還沒有掌握如何使用資料庫。 我不知道可以並行處理進程,並且遍歷所有網路節點花了很長時間,因為... 這發生在一個線程中。 當多個節點不可用時,問題尤其會出現,因為他們每個人都將腳本延遲了 300 毫秒。 在客戶端,有一個簡單的循環函數,每隔幾秒鐘,透過 Ajax 請求從伺服器下載更新的資訊並更新介面。 好吧,那麼,連續3次ping不成功後,如果電腦上打開一個有監控的網頁,就會播放出歡快的樂曲。

當一切順利時,我對結果感到非常鼓舞,並認為我可以添加更多內容(由於我的知識和能力)。 但我一直不喜歡擁有一百萬張圖表的系統,我當時認為,直到今天仍然認為,在大多數情況下這是不必要的。 我只想把真正對我的工作有幫助的東西放在那裡。 時至今日,這項原則仍是 Veliam 發展的基礎。 此外,我意識到,如果我不必保持監控開啟並了解問題,並且當問題發生時,然後打開頁面並查看這個有問題的網路節點位於哪裡以及接下來如何處理它,那將是非常酷的。 不知何故,我當時沒有閱讀電子郵件,我只是沒有使用它。 我在網路上發現有一些簡訊網關,您可以向其發送 GET 或 POST 請求,它們會將我寫的文字發送到我的手機。 我立刻意識到我真的想要這個。 我開始研究文檔。 一段時間後我成功了,現在我的手機上收到了一條關於網絡問題的短信,名為“墜落物體”。 雖然這個系統很原始,但它是我自己寫的,促使我開發它的最重要的一點是它是一個對我的工作確實有幫助的應用程式。

然後有一天,一個網路頻道在工作時出現故障,而我的監控並沒有讓我知道這一點。 由於 Google DNS 仍然可以完美地執行 ping 操作。 是時候考慮如何監控通訊通道是否處於活動狀態。 對於如何做到這一點,存在著不同的想法。 我無法使用所有設備。 我們必須弄清楚如何了解哪些頻道是直播的,但無法以某種方式在網路設備本身上查看它。 然後一位同事想到了一個想法,即根據目前用於訪問互聯網的通訊通道的不同,到公共伺服器的路由追蹤可能會有所不同。 我查了一下,結果是這樣的。 追蹤的時候有不同的路線。

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

因此出現了另一個腳本,或者更確切地說,由於某種原因,追蹤被添加到同一腳本的末尾,該腳本對網路上的所有裝置進行 ping 操作。 畢竟,這又是一個在同一個執行緒中執行的長進程,減慢了整個腳本的工作速度。 但後來就沒那麼明顯了。 但無論如何,他完成了他的工作,程式碼嚴格定義了每個通道應該進行什麼樣的追蹤。 這就是系統開始運作的方式,它已經監控了(大聲說,因為沒有收集任何指標,只是 ping)網路設備(路由器、交換器、wi-fi 等)以及與外界的通訊通道。 簡訊定期到達,圖表總是清楚地顯示問題所在。

而且,在日常工作中,我還要進行交叉。 我厭倦了每次都去思科交換器看看要使用哪個介面。 如果您按一下監控中的物件並查看其介面清單和描述,那該多酷啊。 這會節省我的時間。 此外,在此方案中,無需執行 Putty 或 SecureCRT 來輸入帳戶和命令。 我只是點擊監控,看到需要什麼,然後去做我的工作。 我開始尋找與開關互動的方法。 我立即想到了 2 個選項:SNMP 或透過 SSH 登入交換機,輸入我需要的命令並解析結果。 我之所以放棄 SNMP,是因為它實現的複雜性;我迫不及待地想要得到結果。 使用 SNMP,您必須深入研究 MIB 很長時間,並根據這些資料產生有關介面的資料。 CISCO有一支優秀的團隊

show interface status

它準確地顯示了我對交叉路口的需求。 我想,當我只想查看該命令的輸出時,為什麼要費心使用 SNMP。 一段時間後,我意識到了這個機會。 點選網頁上的物件。 觸發了一個事件,AJAX 客戶端聯繫伺服器,然後伺服器透過 SSH 連接到我需要的交換器(憑證被硬編碼到程式碼中,沒有必要對其進行改進,以製作一些單獨的選單,其中可以從介面更改帳戶,我需要結果並且很快)我在那裡輸入了上述命令並將其發送回瀏覽器。 於是我開始一鍵查看介面資訊。 這非常方便,特別是當您必須同時在不同的交換器上查看此資訊時。

基於追蹤的頻道監控最終並不是最好的主意,因為... 有時工作是在網路上進行的,追蹤可能會發生變化,監控開始向我尖叫,說通道有問題。 但花了很多時間分析後,我意識到所有管道都在工作,我的監控在欺騙我。 因此,我要求管理通道形成交換器的同事在鄰居可見性狀態發生變化時向我發送系統日誌。 因此,它比追蹤更簡單、更快、更準確。 像鄰居丟失這樣的事件已經到來,我立即發出有關頻道關閉的通知。

此外,點擊某個物件時會出現更多指令,並加入 SNMP 來收集一些指標,基本上就是這樣。 該系統從未進一步發展。 它滿足了我所需要的一切,是一個很好的工具。 很多讀者可能會告訴我,網路上已經有很多軟體可以解決這些問題。 但事實上,我當時並沒有在谷歌上搜尋過這樣的免費產品,我真的很想發展我的程式設計技能,還有什麼比真正的應用程式問題更好的方法來推動這一點。 至此,第一版監控完成,不再修改。

成立審計電信公司

隨著時間的推移,我開始在其他公司兼職,幸運的是我的工作時間允許我這樣做。 當你在不同的公司工作時,你各方面的技能成長得很快,你的視野也拓展得很好。 正如他們所說,在有些公司裡,你是一個瑞典人、一個收割者和一個小號手。 一方面,這很困難,另一方面,如果你不懶惰,你就會成為多面手,這可以讓你更快、更有效地解決問題,因為你知道相關領域是如何運作的。

我的朋友 Pavel(也是 IT 專家)不斷嘗試鼓勵我開創自己的事業。 他們有無數的想法,但他們所做的事情卻有不同的變化。 這已經討論了很多年。 最終,它不應該有任何結果,因為我是一個懷疑論者,而帕維爾是一個夢想家。 每次他提出一個想法,我總是不相信,拒絕參與。 但我們真的很想開辦自己的生意。

最後,我們找到了一個適合我們雙方的選擇,並做了我們知道該怎麼做的事情。 2016年,我們決定創立一家IT公司,幫助企業解決IT問題。 這是 IT 系統(1C、終端伺服器、郵件伺服器等)的部署、維護、使用者和網路管理的經典幫助台。

坦白說,在創立公司的時候,我99,9%都不相信。 但不知怎的,帕維爾讓我去嘗試,展望未來,事實證明他是對的。 帕維爾和我每人捐了300 萬盧布,註冊了一家新的有限責任公司“審計電信”,租了一間小辦公室,製作了很酷的名片,嗯,總的來說,就像大多數沒有經驗的新手商人一樣,然後開始尋找客戶。 尋找客戶是一個完全不同的故事。 如果有人有興趣的話,也許我們會寫一篇單獨的文章作為公司部落格的一部分。 推銷電話、傳單等這沒有給出任何結果。 正如我現在讀到的許多有關商業的故事一樣,無論怎樣,很大程度上取決於運氣。 我們很幸運。 公司成立幾週後,我的兄弟弗拉基米爾找到了我們,他為我們帶來了第一個客戶。 我不會讓您厭倦與客戶合作的細節,這不是本文的內容,我只是說我們進行了審核,確定了關鍵領域,並且在決定是否做出決定時,這些領域出現了問題。作為外包商與我們持續合作。 此後,立即做出了積極的決定。

然後,主要是透過朋友的口耳相傳,其他服務公司開始出現。 幫助台位於一個系統中。 與網路設備和伺服器的連接是不同的,或者說是不同的。 有些人保存了快捷方式,其他人則使用 RDP 地址簿。 監控是另一個獨立的系統。 一個團隊在不同的系統中工作是非常不方便的。 重要資訊被忽略。 嗯,例如,客戶端的終端伺服器變得不可用。 立即收到該客戶用戶的申請。 支援專家提出請求(透過電話收到)。 如果事件和請求在一個系統中註冊,那麼支援專家將立即了解使用者的問題是什麼並告訴他,同時連接到所需的物件以解決問題。 每個人都了解戰術情況並協調工作。 我們還沒有找到一個將所有這些結合起來的系統。 很明顯,是時候生產我們自己的產品了。

持續致力於您的監控系統

很明顯,之前寫的系統完全不適合現在的任務。 無論是在功能方面還是在品質方面。 於是決定從頭開始編寫這個系統。 從圖形上看,它應該看起來完全不同。 它必須是一個分層系統,以便能夠快速方便地為正確的客戶開啟正確的物件。 第一個版本中的方案在當前情況下絕對不合理,因為客戶不同,設備位於哪個場所根本不重要。 這已經轉移到文檔中。

所以,任務:

  1. 層次結構;
  2. 某種伺服器部分可以以虛擬機器的形式放置在客戶端的場所,以收集我們需要的指標並將其發送到中央伺服器,中央伺服器將匯總所有這些並向我們顯示;
  3. 警報。 那些不能錯過的,因為... 那時不可能有人坐著看顯示器;
  4. 應用系統。 客戶開始出現,我們不僅為他們提供伺服器和網路設備服務,也為他們提供工作站服務;
  5. 能夠快速連接系統中的伺服器和設備;

任務已經確定,我們開始寫。 一路上,處理客戶的請求。 那時我們已經有4個人了。 我們開始同時編寫兩個部分:中央伺服器和用於安裝到客戶端的伺服器。 至此,Linux 對我們來說不再陌生,我們決定客戶擁有的虛擬機器將在 Debian 上。 不會有安裝程序,我們只需在一台特定的虛擬機器上建立伺服器部分項目,然後將其複製到所需的客戶端。 這是另一個錯誤。 後來發現,在這樣的方案中,更新機制根本就沒有被制定出來。 那些。 我們添加了一些新功能,然後就出現了將其分發到所有客戶端伺服器的整個問題,但我們稍後會回到這個問題,一切都按順序進行。

我們製作了第一個原型。 他能夠 ping 通我們需要的客戶端網路設備和伺服器,並將這些資料傳送到我們的中央伺服器。 反過來,他在中央伺服器上批量更新了這些數據。 在這裡,我不僅會寫一個關於如何成功以及什麼成功的故事,還會寫出哪些業餘錯誤以及後來我如何不得不隨著時間的推移而付出代價。 因此,整個物件樹以序列化物件的形式儲存在一個檔案中。 當我們將多個客戶端連接到系統時,一切都或多或少正常,儘管有時會出現一些完全無法理解的工件。 但當我們將十幾台伺服器連接到系統時,奇蹟開始發生。 有時,由於某種未知的原因,系統中的所有物件都消失了。 這裡要注意的是,客戶端每隔幾秒鐘就會透過 POST 請求向中央伺服器發送資料。 細心的讀者和經驗豐富的程式設計師已經猜到存在對同時從不同執行緒儲存序列化物件的檔案進行多次存取的問題。 就在這一切發生的時候,奇蹟發生了,物體消失了。 該文件只是變空了。 但這一切並沒有立即被發現,而是在多台伺服器運行期間才發現的。 在此期間,新增了連接埠掃描功能(伺服器不僅向中央發送有關設備可用性的信息,還發送有關設備上開啟的連接埠的資訊)。 這是透過呼叫命令來完成的:

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

結果常常不正確,掃描需要很長時間才能完成。 我完全忘記了 ping,它是透過 fping 完成的:

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

這也不是並行的,因此過程非常長。 後來,驗證所需的整個 IP 位址清單立即發送到 fping,然後我們收到了現成的回應者清單。 與我們不同的是,fping 能夠並行化進程。

另一項常見的日常工作是透過WEB 設定一些服務。 例如,來自 MS Exchange 的 ECP。 基本上這只是一個連結。 我們決定需要能夠將此類連結直接添加到系統中,以便不必在文件或書籤中的其他位置找到如何存取特定客戶端的 ECP。 這就是系統資源連結概念的出現方式,它們的功能至今仍然可用,幾乎沒有改變。

資源連結在 Veliam 中的工作原理
從外包到開發(第二部分)

遠端連線

這就是目前版本的 Veliam 中的實際效果
從外包到開發(第二部分)

其中一項任務是快速方便地連接到伺服器,伺服器已經有很多(超過一百個),並且對數百萬個預先儲存的 RDP 快捷方式進行排序非常不方便。 需要一個工具。 互聯網上有類似地址簿的軟體,用於此類 RDP 連接,但它們沒有與監控系統集成,並且無法保存帳戶。 當您每天連接數十次到不同的伺服器時,每次為不同的客戶端輸入帳戶簡直就是地獄。 使用 SSH,情況會好一點;有很多優秀的軟體可以讓您將此類連接組織到資料夾中並記住其中的帳戶。 但有兩個問題。 首先,我們沒有找到用於 RDP 和 SSH 連線的單一程式。 第二個是,如果在某個時候我不在我的電腦旁並且需要快速連接,或者我剛剛重新安裝了系統,我將不得不進入文件以查看該客戶端的帳戶。 既不方便又浪費時間。

我們的內部產品中已經提供了客戶端伺服器所需的層次結構。 我只需要弄清楚如何快速連接到那裡的必要設備。 對於初學者來說,至少在您的網路內。

考慮到我們系統中的客戶端是瀏覽器,無法存取電腦的本地資源,為了簡單地透過一些命令啟動我們需要的應用程序,就發明了透過「Windows自訂 url 方案」。 這就是我們系統中某個「插件」的出現方式,它只包括 Putty 和 Remote Desktop Plus,並且在安裝過程中,只需在 Windows 中註冊 URI 方案。 現在,當我們想要透過 RDP 或 SSH 連線到物件時,我們在系統上按一下此操作,自訂 URI 就可以運作了。 啟動了 Windows 或 putty 中內建的標準 mstsc.exe,它是「插件」的一部分。 我將插件一詞放在引號中,因為這不是傳統意義上的瀏覽器插件。

至少那是一些東西。 方便的地址簿。 此外,就 Putty 而言,一切通常都很好;可以將 IP 連接、登入名稱和密碼作為輸入參數。 那些。 我們已經一鍵連接到網路上的 Linux 伺服器,無需輸入密碼。 但對於 RDP,事情就沒那麼簡單了。 標準 mstsc 無法提供憑證作為參數。 遠端桌面增強版來了。 他允許這件事發生。 現在我們可以不用它了,但很長一段時間它都是我們系統中忠實的助手。 對於 HTTP(S) 站點,一切都很簡單,只需在瀏覽器中開啟此類物件即可。 方便實用。 但這只是在內網的幸福。

由於我們從辦公室遠端解決了絕大多數問題,因此最簡單的事情就是向客戶提供 VPN。 然後就可以從我們的系統連接到它們。 但還是有些不方便。 對於每個用戶端,需要在每台電腦上保留一堆記住的VPN連接,並且在連接到任何VPN之前,需要啟用相應的VPN。 我們使用這個解決方案很長一段時間。 但客戶端的數量正在增加,VPN 的數量也在增加,所有這些都開始變得緊張,必須採取一些措施。 重新安裝系統後,當我必須在新的 Windows 設定檔中重新輸入數十個 VPN 連線時,我的眼淚尤其奪眶而出。 我說,別再忍受了,並開始思考我能做些什麼。

碰巧所有客戶端都使用了知名公司 Mikrotik 的設備作為路由器。 它們非常實用且方便,幾乎可以執行任何任務。 缺點是它們被「劫持」了。 我們簡單地透過關閉所有來自外部的存取來解決這個問題。 但有必要以某種方式在不去客戶那裡的情況下接觸到它們,因為… 它的長。 我們只是為每個這樣的 Mikrotik 製作隧道,並將它們分成一個單獨的池子。 沒有任何路由,因此您的網路與客戶端的網路以及它們的網路彼此之間沒有連接。

這個想法的誕生是為了確保當我點擊系統中我需要的對象時,中央監控伺服器知道所有客戶端 Mikrotik 的 SSH 帳戶,連接到所需的對象,並使用以下命令創建到所需主機的轉發規則:所需連接埠。 這裡有幾點。 該解決方案並不通用 - 它僅適用於 Mikrotik,因為所有路由器的命令語法都不同。 此外,此類轉發必須以某種方式刪除,而且我們系統的伺服器部分基本上無法以任何方式追蹤我是否已完成 RDP 會話。 嗯,這樣的轉送對於客戶端來說是一個漏洞。 但我們並不追求普遍性,因為… 該產品僅在我們公司內部使用,並沒有向公眾發布的想法。

每個問題都以自己的方式解決。 建立規則後,此轉送僅適用於一個特定的外部 IP 位址(從該位址初始化連線)。 因此避免了安全漏洞。 但對於每個這樣的連接,Mikrotik 規則都會新增到 NAT 頁面並且不會被清除。 大家都知道,規則越多,路由器處理器的負載就越多。 總的來說,我無法接受有一天我去某個 Mikrotik,那裡會出現數百條死的、無用的規則。

由於我們的伺服器無法追蹤連線狀態,因此讓 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 的備份配置為 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');

?>

備份以兩種形式進行 - 二進位和文字配置。 二進位檔案有助於快速恢復所需的配置,文字檔案可以讓您了解如果強制更換設備並且二進位檔案無法上傳到設備,需要做什麼。 結果,我們在系統中獲得了另一個方便的功能。 此外,在新增的 Mikrotik 時,無需配置任何內容;我只需將物件新增至系統並透過 SSH 為其設定帳戶即可。 然後系統本身負責備份。 目前版本的 SaaS Veliam 尚不具備此功能,但我們很快就會移植它。

內部系統的截圖
從外包到開發(第二部分)

過渡到普通資料庫存儲

我在上面已經寫到出現了文物。 有時系統中的整個物件清單消失了,有時在編輯物件時,資訊未儲存且物件必須重新命名三次。 這讓所有人都非常惱火。 物件消失的情況很少發生,並且透過恢復該檔案很容易恢復,但編輯物件時失敗的情況卻經常發生。 也許,我最初沒有透過資料庫來做到這一點,因為它不符合我的想法,如何在一個平面表中保留一棵包含所有連接的樹。 它是扁平的,但樹是分層的。 但對於多重存取以及隨後(隨著系統變得更加複雜)事務而言,DBMS 是一個很好的解決方案。 我可能不是第一個遇到這個問題的人。 我開始谷歌搜尋。 事實證明,一切都在我之前被發明了,並且有幾種演算法可以從平面表建立一棵樹。 在查看了每一項之後,我實施了其中一項。 但這已經是新版的系統了,因為… 事實上,正因為如此,我不得不重寫很多東西。 結果很自然,系統隨機行為的問題消失了。 有人可能會說,在軟體開發領域,這些錯誤非常業餘(單線程腳本、在文件中存儲從不同線程同時訪問多次的信息等)。 也許這是真的,但我的主要工作是管理,程式設計是我靈魂的副業,而且我根本沒有在程式設計師團隊中工作的經驗,在這種情況下,我的前輩會立即向我建議這些基本的事情同志們。 因此,我自己填補了所有這些坎坷,但我把材料學得很好。 而且,我的工作還包括與客戶會面、旨在推廣公司的行動、公司內部的一系列行政問題等等。 但無論怎樣,已有的東西仍然存在需求。 我和我自己在日常工作中使用了該產品。 坦白說,有一些不成功的想法和解決方案,浪費了時間,但最終很明顯,這不是一個可行的工具,沒有人使用它,它也沒有最終出現在 Veliam 中。

服務台 - 服務台

提及 HelpDesk 是如何形成的也無可厚非。 這是一個完全不同的故事,因為… 在 Veliam,這已經是第三個全新版本,與之前的所有版本不同。 現在它是一個簡單的系統,直觀,沒有不必要的花哨,能夠與網域集成,以及使用電子郵件中的連結從任何地方訪問相同的用戶配置文件的能力。 最重要的是,可以從任何地方(家中或辦公室)直接從應用程式透過 VNC 連接到申請人,無需 VPN 或連接埠轉送。 我會告訴你我們是如何走到這一步的,之前發生了什麼,以及做出了哪些可怕的決定。

我們透過著名的 TeamViewer 與用戶建立聯繫。 我們服務的用戶的所有電腦都安裝了電視。 我們做錯的第一件事是將每個高清客戶端連接到硬件,然後將其刪除。 使用者如何登入HD系統以留下請求? 除了電視之外,每個人的電腦上都安裝了一個用Lazarus 編寫的特殊實用程式(這裡很多人會翻白眼,甚至可能去Google 一下它是什麼,但我所知道的最好的編譯語言是Delphi, Lazarus 幾乎是)同樣的事情,只是免費)。 一般來說,使用者啟動一個特殊的批次檔來啟動該實用程序,該實用程式依序讀取系統的 HWID,然後啟動瀏覽器並進行授權。 為什麼要這樣做? 有些公司是單獨統計服務使用者數量,每個月的服務價格是依照人數來計算的。 你說這是可以理解的,但為什麼它與硬體掛鉤呢? 很簡單,有些人回到家,用家裡的筆記型電腦提出了「讓這裡的一切都為我而美麗」的請求。 除了讀取系統 HWID 之外,該實用程式還會從登錄中提取目前的 Teamviewer ID 並將其傳輸給我們。 Teamviewer 有一個用於整合的 API。 我們進行了這種整合。 但有一個問題。 透過這些API,如果使用者沒有明確發起此會話,則無法連接到使用者的計算機,並且在嘗試連接到該計算機後,也必須按一下「確認」。 當時,對我們來說,在沒有用戶請求的情況下任何人都不應進行連接似乎是合乎邏輯的,並且由於該人位於計算機旁,因此他將發起會話並對遠端連接請求做出肯定響應。 結果一切都錯了。 申請人忘記按啟動會話,必須在電話交談中告訴他們這一點。 這不僅浪費了時間,而且讓整個過程雙方都感到沮喪。 此外,這樣的情況並不罕見:一個人提出請求,但只有在他去吃午餐時才允許連接。 因為問題並不嚴重,他不希望自己的工作進程被打斷。 因此,他不會按下任何按鈕來允許連接。 這就是登入 HelpDesk 時出現附加功能的方式 - 讀取 Teamviwer 的 ID。 我們知道安裝 Teamviwer 時所使用的永久密碼。 更準確地說,只有系統知道它,因為它是內建在安裝程式和我們的系統中。 因此,應用程式中有一個連接按鈕,按一下該按鈕無需等待任何事情,但 Teamviewer 立即開啟並發生連線。 因此,存在兩種可能的連接。 透過官方的 Teamviewer API 和我們自製的 API。 令我驚訝的是,他們幾乎立即停止使用第一個,儘管有指示僅在特殊情況下以及用戶本人同意時才使用它。 不過,現在就給我安全感吧。 但事實證明,申請人並不需要這個。 它們完全可以在沒有確認按鈕的情況下連接到它們。

在 Linux 中切換到多線程

為預先確定的連接埠清單的開放性和網路物件的簡單 ping 操作而加速網路掃描器的通過的問題早已開始出現。 當然,首先想到的解決方案是多執行緒。 由於 ping 的主要時間是等待資料包返回,而只有前一個資料包返回後才能開始下一次 ping,因此即使在擁有 20 多台伺服器加上網路設備的公司中,這也已經相當緩慢了。 關鍵是一個套件可能會消失,但不要立即通知系統管理員。 他很快就會停止接受這類垃圾郵件。 這表示您需要對每個物件多次 ping 操作才能得出不可存取的結論。 在不涉及太多細節的情況下,有必要將其並行化,因為如果不這樣做,那麼系統管理員很可能會從客戶端而不是從監控系統了解問題。

PHP 本身不支援開箱即用的多執行緒。 能夠進行多處理,您可以分叉。 但是,事實上,我已經編寫了一個輪詢機制,我想這樣做,以便我可以從資料庫中計算我需要的所有節點,立即對所有節點進行ping 操作,等待每個節點的回應,並且只有在之後立即寫入資料。 這節省了讀取請求的數量。 多線程非常適合這個想法。 對於 PHP,有一個 PThreads 模組,讓您可以進行真正的多執行緒處理,儘管在 PHP 7.2 上進行了相當多的修改才能設定它,但它已經完成了。 連接埠掃描和 ping 現在很快。 例如,這個過程開始需要 15 秒,而不是之前每圈 2 秒。 這是一個很好的結果。

新公司快速審核

收集各種指標和硬體特徵的功能是如何產生的? 這很簡單。 有時我們只是被命令審計目前的 IT 基礎設施。 好吧,為了加快新客戶的審核速度,同樣的事情也是必要的。 我們需要一些東西,讓我們能夠進入一家中型或大型公司並快速了解他們擁有什麼。 在我看來,只有那些想讓自己的生活變得複雜的人才會阻止內部網路上的 ping,而根據我們的經驗,這樣的人很少。 但也有這樣的人。 因此,您可以透過簡單的 ping 操作快速掃描網路中是否存在裝置。 然後我們可以添加它們並掃描我們感興趣的開放端口。 事實上,這個功能已經存在;只需要從中央伺服器向從屬伺服器添加一條命令,以便它掃描指定的網路並將其發現的所有內容添加到清單中。 我忘了提及,假設我們已經有了一個帶有配置系統(從屬監控伺服器)的現成映像,我們可以在審核期間簡單地從客戶端推出並將其連接到我們的雲端。

但審核的結果通常包含一堆不同的訊息,其中之一是網路上的設備類型。 首先,我們對作為網域一部分的 Windows 伺服器和 Windows 工作站感興趣。 因為在中型和大型公司中,缺乏域可能是一個例外。 在我看來,要說一種語言,平均有 100 多人。 有必要想出一種方法來收集所有 Windows 電腦和伺服器的數據,以了解它們的 IP 和網域管理員帳戶,但無需在每台電腦上安裝任何軟體。 WMI 介面可以解決這個問題。 Windows Management Instrumentation (WMI) 字面意思是 Windows 管理工具。 WMI是集中管理和監控運行Windows平台的電腦基礎設施各部分運作情況的基本技術之一。 摘自維基。 接下來,我必須再次修補才能為 Debian 編譯 wmic(這是一個 WMI 用戶端)。 一切準備就緒後,剩下的就是透過 wmic 輪詢必要的節點以獲取必要的資訊。 透過WMI你幾乎可以從Windows計算機上獲取任何信息,此外,你還可以透過它控制計算機,例如發送它重新啟動。 這就是我們系統中有關 Windows 網站和伺服器的資訊集合的出現方式。 除此之外,還有目前系統負載指標的最新資訊。 我們更頻繁地請求它們,而更少地請求有關硬體的資訊。 從此以後,審計變得更加愉快了。

軟體分發決策

我們自己每天都在使用該系統,並且它始終對每位技術員工開放。 我們認為我們可以與他人分享我們已經擁有的東西。 該系統尚未準備好分發。 為了將本地版本轉變為 SaaS,需要進行大量修改。 其中包括系統各個技術方面的變化(遠端連接、支援服務)、許可模組分析、客戶資料庫分片、每項服務的擴展以及所有部分的自動更新系統的開發。 但這將是本文的第二部分。

更新消息

第二部分

來源: www.habr.com

添加評論