所有 1C 開發人員都以某種方式與 IT 服務並直接與系統管理員密切互動。 但這種互動並不總是順利。 我想告訴你一些關於這件事的有趣的故事。
高速通訊頻道
我們的客戶大多是大型企業，擁有自己的大型 IT 部門。 客戶專家通常負責資訊資料庫的備份副本。 但也有相對較小的組織。 特別是對於他們，我們提供了一項服務，根據該服務，我們承擔與所有 1C 內容備份相關的所有問題。 這就是我們在這個故事中要討論的公司。
一個新客戶來支援 1C，除其他外，合約中包括一項由我們負責備份的條款，儘管他們有自己的系統管理員。 客戶端伺服器資料庫，MS SQL 作為 DBMS。 這是一個相當標準的情況，但還有一個細微差別：主基數相當大，但每個月的增幅卻很小。 也就是說，資料庫包含了大量的歷史資料。 考慮到這個特點，我制定的備份維護計劃是這樣的：每個月的第一個週六做一次完整備份，相當重，然後每天晚上做一份差異副本——體積比較小，還有一份每小時一次的交易日誌。 此外，完整副本和差異副本不僅複製到網路資源，還上傳到我們的 FTP 伺服器。 這是提供此服務時的強制性要求。
所有這些都已成功配置、投入運行並且通常正常運行，沒有出現任何故障。
但幾個月後，這個組織的系統管理員發生了變化。 新的系統管理員開始按照現代趨勢逐步重建公司的IT基礎架構。 特別是虛擬化的出現，磁碟架，存取到處都被阻止等等，這在一般情況下當然不能不值得慶幸。 但事情並不總是一帆風順，1C的表現經常出現問題，導致與我們的支持產生一些分歧和誤解。 另外，應該指出的是，我們與他的關係總體上相當冷淡，有些緊張，一旦出現任何問題，這只會增加緊張程度。
但有一天早上發現這個客戶端的伺服器不可用。 我打電話給系統管理員，想了解發生了什麼，得到的答覆是“我們的伺服器崩潰了，我們正在處理它，不取決於你。” 嗯，他們工作很好。 這意味著局勢已得到控制。 午餐後，我再次打電話，從管理員的聲音中我已經不再感到惱怒，而是疲倦和冷漠。 我想弄清楚發生了什麼事，我們可以提供什麼幫助嗎？ 談話的結果如下：
他將伺服器轉移到一個新的儲存系統，並配備了新組裝的raid。 但出了點問題，幾天後這次突襲安全失敗了。 到底是控制器燒壞了，還是磁碟出了問題，我記不太清楚了，但所有的資訊都遺失了，無法挽回。 最主要的是，在各種遷移過程中，具有備份的網路資源也最終位於同一個磁碟陣列上。 也就是說，生產資料庫本身及其所有備份副本都遺失了。 現在還不清楚該怎麼辦。
冷靜點，我說。 我們有您的夜間備份。 周圍一片寂靜，我意識到我剛剛救了一個人的命。 我們開始討論如何將此副本傳輸到新部署的新伺服器。 但這裡也出現了一個問題。
還記得我說過完整備份相當大嗎？ 我每個月在星期六這樣做一次並不是沒有原因的。 事實上，該公司是一家小工廠，距離城很遠，網路也很一般。 到週一早上，也就是週末，這個副本才勉強上傳到我們的 FTP 伺服器。 但不可能等一兩天才能讓它以相反的方向加載。 幾次嘗試傳輸文件失敗後，管理員直接從新伺服器上取出了硬碟，在某處找到了一輛有司機的車，迅速趕到了我們的辦公室，幸好我們還在同一個城市。
當他們站在我們的伺服器機房等待文件被複製時，我們第一次見面，可以說是“面對面”，喝了一杯咖啡，並在非正式的環境中交談。 我對他的悲痛表示同情，並帶著一整套備份送他回來，匆忙地恢復了公司停止的工作。
隨後，我們向IT部門提出的所有要求都很快得到了解決，沒有再出現任何分歧。
請聯絡您的系統管理員
有一次，在很長一段時間裡，我無法為一個客戶端發布透過 IIS 進行 Web 存取的 1C。 這似乎是一個普通的任務，但沒有辦法讓一切運作起來。 本機系統管理員參與其中並嘗試了不同的設定和設定檔。 網路上的 1C 通常不想以任何方式工作。 出了問題，要嘛是網域安全策略，要嘛是本地複雜的防火牆，或是天知道還有什麼問題。 在第 N 次迭代中，管理員向我發送了一個鏈接，其中包含以下內容：
- 使用這些說明重試。 那裡對一切都進行了非常詳細的描述。 如果不起作用，請寫信給該網站的作者，也許他可以提供幫助。
“不，”我說，“這沒有幫助。”
- 為什麼？
— 我是這個網站的作者...（
結果，我們在 Apache 上啟動它沒有任何問題。 IIS 從未被擊敗。
更深一層
我們有一個客戶—一家小型製造企業。 他們有一台伺服器，一個「經典」的三合一：終端伺服器+應用程式伺服器+資料庫伺服器。 他們在一些基於 UPP 的行業特定配置中工作，大約有 3-1 個用戶，系統的性能原則上適合每個人。
隨著時間的推移，一切都或多或少地穩定進行。 但隨後歐洲對俄羅斯實施制裁，俄羅斯人開始主要購買國產產品，該公司的業務急劇惡化。 用戶數量增加到50-60人，開設了新的分支機構，文件流量也相應增加。 而現在目前的伺服器已經無法應對急劇增加的負載，正如他們所說，1C開始「放慢速度」。 在高峰時段，文件的處理時間為幾分鐘，出現阻塞錯誤，表格需要很長時間才能打開，以及所有其他一系列相關服務。 本地系統管理員對所有問題都置之不理，說：“這是你的 1C，你會解決的。” 我們曾多次提出對系統進行效能審計，但從未涉及審計本身。 客戶只是詢問如何解決問題的建議。
好吧，我坐下來寫了一封相當長的信，關於需要將終端伺服器和應用程式伺服器與 DBMS 的角色分開（原則上，我們之前已經說過很多次了）。 我寫了有關終端伺服器上的 DFSS、共享內存的文章，提供了權威來源的鏈接，甚至建議了一些設備選項。 這封信到達了公司的掌權者手中，並帶著「實施」的決議回到了 IT 部門，僵局基本上被打破了。
一段時間後，管理員向我發送新伺服器的 IP 位址和登入憑證。 他說，MS SQL和1C伺服器元件部署在那裡，資料庫需要轉移，但目前只能轉移到DBMS伺服器，因為1C金鑰出現了一些問題。
我進來了，確實，所有服務都在運行，伺服器不是很強大，但好吧，我認為有總比沒有好。 我現在將轉移資料庫，以某種方式緩解當前伺服器的壓力。 我在約定的時間完成了所有的轉賬，但情況沒有改變——仍然是同樣的效能問題。 當然很奇怪，好吧，我們把資料庫註冊到1C叢集中看看吧。
幾天過去了，鑰匙還沒轉移。 我想知道問題是什麼，一切似乎都很簡單 - 將其從一台伺服器中取出，插入另一台伺服器，安裝驅動程序，然後就完成了。 管理員的回應是大驚小怪，並說了一些有關連接埠轉送、虛擬伺服器等的內容。
嗯...虛擬伺服器？ 似乎從來沒有任何虛擬化，也從來沒有任何......我記得一個相當著名的問題，即無法將 1C 伺服器金鑰轉發到 Windows Server 2008 中 Hyper-V 上的虛擬機器。我心裡開始產生一些懷疑…
我打開伺服器管理員-角色-出現了一個新角色-Hyper-V。 我轉到 Hyper-V 管理器，看到一台虛擬機，連接...確實...我們的新資料庫伺服器...
所以呢？ 當局的指示和我的建議已經執行，角色已經分開。 任務可以關閉。
一段時間後，現在的危機發生了，新的分支不得不關閉，負載下降，系統效能變得或多或少可以忍受。
當然，他們無法將伺服器金鑰轉發到虛擬機器。 結果，一切都保持原樣：終端伺服器+1C叢集在實體機上，資料庫伺服器在虛擬機器上。
如果這是某種沙拉甚金的辦公室那就太好了。 所以不行。 一家知名公司，您可能知道並在所有倫塔和歐尚的相關部門見過其產品。
硬碟假期安排
一家有著雄心勃勃的計劃接管世界的大型控股公司再次收購了一家小公司，目標是將其納入其大型企業。 在該控股公司的所有部門中，使用者都在自己的資料庫中工作，但配置相同。 因此，我們啟動了一個小項目，在該系統中包含一個新單元。
首先，需要部署生產資料庫和測試資料庫。 開發人員收到連接數據，登入伺服器，看到安裝了 MS SQL，1C 伺服器，看到 2 個邏輯驅動器：容量為 250 GB 的驅動器“C”和容量為 1 TB 的驅動器“D”。 那麼，「C」就是系統，「D」是數據，開發人員邏輯上決定並部署所有資料庫。 我甚至制定了維護計劃，包括備份，以防萬一（儘管我們對此不負有責任）。 確實，備份已添加到“D”。 將來，計劃將其重新配置為某些單獨的網路資源。
專案開始了，顧問提供瞭如何在新系統中工作的培訓，剩餘的內容被轉移，進行了一些小的改進，使用者開始在新的資訊庫中工作。
一切都很順利，直到一個星期一早上，發現資料庫磁碟遺失了。 伺服器上根本就沒有“D”，僅此而已。
進一步調查發現：這個「伺服器」其實是本機系統管理員的工作電腦。 確實，它仍然有一個伺服器作業系統。 此管理員的個人 USB 隨身碟已插入伺服器。 於是，管理員帶著他的螺絲釘去度假了，目的是為了在旅途中拍攝電影。
感謝上帝，他沒有刪除資料庫檔案並成功恢復了生產資料庫。
值得注意的是，每個人都對 USB 驅動器上的系統的性能普遍感到滿意。 沒有人抱怨1C的表現有任何不理想的地方。 直到後來，該控股公司才開始了一個大型項目，將所有資訊資料庫轉移到一個單一的集中站點，其中包括超級伺服器、超過一百萬盧布的儲存系統、複雜的虛擬機器管理程序以及所有分支機構中難以忍受的1C 煞車。
但這是一個完全不同的故事......
來源： www.habr.com