這個時期一般需要滿足基礎監控需求，我們主要考慮的是簡單易用、 穩定執行、 監控報警三個方面。

雲幫手資源監控系統全程視覺化介面，一鍵傻瓜式操作，新手小白也能快速上手；能夠從CPU、記憶體、磁碟、網路四個方面對伺服器進行24小時不間斷基礎監控，並可自主設定告警規則，在狀態異常時第一時間產生告警，幫助使用者快速定位問題解決問題。

可以跳轉這個連結去官網看看https://www.cloudx.cn/?utm_source=wu-wk

機器數比較小的話，你可以用雲的伺服器，這樣可以節省好多錢。找一個專門的運維，還不如讓開發自己來搞，因為機器少運維他也應付得過來。現在都在搞雲計算了，把你的機器放上阿里雲或者騰訊雲，你自己維護好很多，包括網路貸款都很容易擴容。上面這個我說到的只是說建議你如果你已經是自己的機器了。我建議你從我下面所說的來搞。

認為的整個過程的話一般分為三個階段，第一的話是手工階段，什麼東西都是手工搞。

第2個階段就是指令碼階段了，本來手工搞的東西全部指令碼化。

第3個階段就是平臺化了，平臺化了之後，所有東西都在頁面上完成系統完成，不需要人工來干預，甚至不用運維來搞。

有一些人說既然認為就是最後的一個階段，但是這個很不成熟。所以我就不說了。

針對你這個機器數少的，你可以手工認為，或者說用指令碼認為都沒問題。

在合適的階段做合適的事情就是最好的。所以我建議你手工運維或者指令碼運維。

題主沒有詳細說明具體應用系統的功能，比如是否單一的Web服務？有沒有微服務、分散式、叢集化擴充套件的潛在需求？

通常來說，建議使用雲服務自動化運維。雲服務已經成為IT技術的核心基礎設施，充分利用雲服務帶來的彈性和分散式優勢，賦能自動化運維。

如果需要構建應用，那麼就建議配置使用CI/CD持續化整合和自動化部署，比如常用的Jenkins，配置Git程式碼提交時觸發構建，然後自動部署。

1，ELK是常見的日誌收集管理系統，包括ElasticSearch, LogStash, Kibana三個服務，架構示意圖如下：

2，在ELK系統中，Kibana是一個圖形化展示工具，配置查詢條件，運維人員隨時可以搜尋指定日誌資訊，分析處理故障。

1，雲監控CloudMonitor

主流雲服務商都將監控功能整合到了基礎架構中，以阿里云為例，雲監控提供了多種配置，多維度全方位監控。

比如配置CPU使用率到達80%時，自動觸發動作，增加伺服器例項，同時郵件通知運維人員。

2，應用監控

以監控寶為例，配置服務地址，選擇分佈在不同地區和運營商的監測點。當監測點不能正常呼叫配置的服務地址時，將收到警告資訊，可以選擇郵件、簡訊、電話等通知方式。

1，是否叢集化部署？需要AutoScaling自動伸縮嗎？

小型化和叢集化並不衝突。如果採用叢集化部署，可以配置觸發條件，滿足時自動增加或者釋放伺服器資源。比如當CPU使用率達到75%或者記憶體佔用率達到75%時，根據配置好的伺服器和數量，自動觸發。

2，是否使用Docker容器技術？

Docker將應用以及依賴打包到一個可移植的映象中，可以實現虛擬化，有助於快捷高效的交付應用，結合Docker-compose資源編排，快速實現自動部署更新，不再需要常用的Jenkins構建伺服器。

我們可以從以下幾方面來開展我們的運維工作：

1.應用伺服器

我們可以從當前伺服器中找出至少2個節點裝Vsphere虛擬化，建立一個數據中心、叢集；如果你的伺服器有多網絡卡和SCSI，還可以做一些更高階的應用，如vmotion、負載均衡、高可用等。當虛擬機器或伺服器故障，可以實現故障自動轉移，有效的避免了單節點的故障，提供伺服器的容錯率。

我們可以在新建的虛擬機器部署Web、API等各種應用，而且虛擬機器可以在vCenter圖形化介面下統一管理。這一般是中小公司的在伺服器方面的解決方案。

當然，我們對docker比較熟悉，可以使用一套docker解決方案，這比Vsphere更能節省一部分資源。當然這個需要的技能要求也比較高，需要我們不斷積累。

2.資料庫伺服器

資料庫伺服器在此我們單獨拿出來，是因為資料庫對伺服器效能、磁碟IO要求比較高，不太建議使用虛擬機器，當然這需要根據業務的實際情況來做選擇。資料庫我們需要透過一主一從、一主二從的方式實現高可用，來避免資料庫單點問題，我們還可以選擇合適的proxy來進行讀寫分離、讀負載均衡等。另外還要考慮資料的本地備份、異地備份，來確保資料可恢復。

3.系統監控

當我們在應用伺服器和資料庫伺服器上線一套系統後，我們需要透過監控掌握從伺服器硬體、基礎狀態、應用、資料庫等從下到上的執行狀態，以便我們能夠對告警及時做出響應。考慮到報警的及時性，我們需要監控接入多種報警渠道，如微信、釘釘、郵件、簡訊等。監控的目的是發現問題、解決訪問，因此我們需要踏實的做好這一步，才能為我們的業務保駕護航。

伺服器數量比較少，比如10臺伺服器，基本可以不設定運維崗位了，後端開發人員 或者架構師就能搞定。

我就是那種曾經在創業的小公司待過的開發人員，開發，運維我都幹了。

但是想想如何更科學更高效的運維還是很有必要的。

軟體系統的執行時環境：即公司的業務產線，靠它創造業務價值，這個是最核心的功能訴求。

實時監控系統: 任何時候都要對當前公司的產線的壓力一清二楚，有問題功能隨時解決，有效能問題及時擴容或者回收資源

降低伺服器成本：在業務萎縮的情況下，準確評估哪些資源可以回收，降低伺服器的支出

這個是當時我認為的運維的三個主要目的。

開發半路出家，當時採用的是shell+python+ansible+jekins+elk的方式

首先，我會及時的更新業務產線的物理架構圖，根據架構圖來規劃伺服器的資源使用。

比如多少個web服務，資料庫多少，zk,kafka,redis叢集怎麼分佈。

叢集部署一般是放在多個伺服器上的，這個時候ansible就派上用場了。

jekins主要用來自動釋出更新程式已經做定時回收磁碟的任務。

elk主要用來做應用的日誌系統和監控告警； 可以透過看板隨時知道產線的請求數量和併發數量；

以上的運維方案適用於小公司。運維工程師看到了可以補充

運維人員的工作每天基本上都是在檢查問題，枯燥但又重要，要是你的某一個環節出現問題並沒有及時發現問題，對於企業來說損失可能非常大，基本上運維人每天的工作我羅列了下，有這幾種：

1、負責伺服器的硬體配置、軟體安裝、機房上下架等技術維護工作

2、負責虛擬化技術產品物理機配置、管理和日常執行監控和維護

3、負責獨立主機或虛擬應用產品的開通使用、日常維護、故障診斷和排除

4、提供獨立主機或虛擬應用客戶產品操作和應用方面的技術支援

5、監視分管的伺服器，及時發現問題，並積極解決問題

1.支援跨雲商批次管理伺服器

2.相容性強大，相容市面基本所有的雲商雲主機，相容作業系統；

3.操作簡單，視覺化介面預覽資源、一鍵修復、一鍵部署；

4. 可以遠端登入雲主機FTP桌面，處理雲主機上的檔案；

5.監控和資源還有告警功能，這個是挺好的，不用盯著看；

6.系統修復功能，這個是挺實用也比較必須的；

7.免費使用。總得來說功能還是挺全的，不存在需要又要另外找軟體的尷尬。

我們專案用的wgcloud運維監控系統，它前身是開源專案，後來推出的商業版，也有免費版

wgcloud執行很穩定，效能很好，部署和上手容易

wgcloud支援主機各種指標監控(cpu狀態/溫度，記憶體狀態，磁碟容量/IO，硬碟smart監控，系統負載，網絡卡流量，硬體系統資訊等)，資料視覺化，程序應用監控，大屏視覺化，服務介面檢測，DOCKER監控，自動生成網路拓撲圖，埠監控，日誌檔案監控，web SSH（堡壘機），指令下發執行，告警資訊推送（郵件釘釘微信簡訊等）