A. 問下雲服務貴嗎
雲伺服器作為一種簡單高效、處理能力可彈性伸縮的計算服務，性價比高，可以按需購買資源，價格並不算貴。
有些用戶覺得雲伺服器比虛擬主機貴，這是因為雲主機是獨立資源，而虛擬主機是共享資源，無論是安全穩定性、訪問速度、資源升級拓展等，雲主機的性能都要比虛擬主機優異很多，所以價格也要相應貴一些。
從成本方面來講，雲計算伺服器所需要付出的也遠比用戶想像的多。
1.硬體設施成本
硬體成本主要是采購伺服器、交換機及其零部件，實力雄厚的大廠還會采購硬體負載均衡和硬體存儲，科研機構還會自研整櫃伺服器。IT基礎設施包括：入門伺服器折舊費、伺服器軟體折舊費、伺服器能耗費用及場地租金、維護管理設備的人力資源費用和保存文件的其它支出等等。
2.機房電力和網路成本
電力是機房實打實的資源，IDC要24小時不間斷供電。大型雲服務商都是自營無利潤IDC、整櫃伺服器、高效散熱系統，高品質機房的電力成本可想而知。網路成本包含IP和帶寬，IP地址資源緊張，費用較貴。帶寬是雲計算運營的硬成本。此外，還有還有ddos攻擊問題、IP段被污染問題、ICP備案問題也在提高網路成本。
3.資源閑置成本
巨大的伺服器采購體量必然會造成極大的資源閑置，假設一次采購上架200櫃伺服器，那就要售出5萬台虛擬機才能充分利用硬體。硬體從上架之時就在不停的折舊。
4.技術人力成本
對雲主機公司來說，高薪招攬技術人才可以提高公司核心競爭力，也是客戶後期技術支持的保障。而一般技術員工待遇都比較高，所以技術和人力也是非常大的支出。
雲伺服器怎麼算費用的
雲伺服器是一種簡單高效、處理能力可彈性伸縮的計算服務， 幫助您快速構建更穩定、安全的應用，提升運維效率，降低IT成本。在購買雲伺服器時，費用主要在這些方面：CPU、內存、帶寬，以及硬碟大小，此外輔助的快照功能、安全防護等。
雲伺服器費用支付模式，有包年包月、按時付費。
B. 伺服器數量比較少，怎麼運維比較好
運維人員的工作每天基本上都是在檢查問題，枯燥但又重要， 要是你的某一個環節出現問題並沒有及時發現問題，對於企業來說損失可能非常大，基本上運維人每天的工作我羅列了下，有這幾種：
1、負責伺服器的硬體配置、軟體安裝、機房上下架等技術維護工作
2、負責虛擬化技術產品物理機配置、管理和日常運行監控和維護
3、負責獨立主機或虛擬應用產品的開通使用、日常維護、故障診斷和排除
4、提供獨立主機或虛擬應用客戶產品操作和應用方面的技術支持
5、監視分管的伺服器，及時發現問題，並積極解決問題
現在信息化數字時代，單靠人工去檢查出現錯誤幾率會很大，而且有的運維人還不只管理兩台伺服器，像我們公司的運維每人至少要管理30台伺服器，這樣子單靠人工運維耗費的人工成本和時間是非常大的，所以還是推薦你用運維工具吧，比如雲幫手（）1.支持跨雲商批量管理伺服器
2.兼容性強大，兼容市面基本所有的雲商雲主機，兼容操作系統；
3.操作簡單，可視化界面預覽資源、一鍵修復、一鍵部署；
4. 可以遠程登錄雲主機FTP桌面，處理雲主機上的文件；
5.監控和資源還有告警功能，這個是挺好的，不用盯著看；
6.系統修復功能，這個是挺實用也比較必須的；
7.免費使用。總得來說功能還是挺全的，不存在需要又要另外找軟體的尷尬。
你好，很高興回答你這個問題。從運維的角度來講，伺服器的數量少並不意味著我們的運維工作就非常輕松，相反我們更應該重視此階段的工作。
我們可以從以下幾方面來開展我們的運維工作：
1.應用伺服器
我們可以從當前伺服器中找出 至少2個節點裝Vsphere虛擬化，建立一個數據中心、集群 ；如果你的伺服器有多網卡和SCSI，還可以做一些更高級的應用，如vmotion、負載核岩仿均衡、高可用等。當虛擬機或伺服器故障，可以 實現故障自動轉移，有效的避免了單節點的故障，提供伺服器的容錯率 。
我們可以在新建的虛擬機部署Web、API等各種應用，而且 虛擬機可以在vCenter圖形化界面下統一管理 。這一般是中小公司的在伺服器方面的解決方案。
當然，我們對docker比較熟悉，可以使用一套docker解決方案，這比Vsphere更能節省一部分資源。當然這個需要的技能要求也比較高，需要我們不斷積累。
2.資料庫伺服器
資料庫服務棗手器在此我們單獨拿出來，是因為資料庫對伺服器性能、磁碟IO要求比較高，不太建議使用虛擬機，當然這需要根據業務的實際情況來做選擇。 資料庫我們需要通過一主一從、一主二從的方式實現高可用，來避免資料庫單點問 題，我們還可以選擇合適的proxy來進行讀寫分離、讀負載均衡等。另外還要考慮數據的本地備份、異地備份，來確保數據可恢復。
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構建伺服器。
機器數比較小的話，你可以用雲的伺服器，這樣可以節省好多錢。找一個專門的運維，還不如讓開發自己來搞，因為機器少運維他也應付得過來。現在都在搞雲計算了，把你的機器放上阿里雲或者騰訊雲，你自己維護好很多，包括網路貸款都很容易擴容。上面這個我說到的只是說建議你如果你已經是自己的機器了。我建議你從我下面所說的來搞。
認為的整個過程的話一般分為三個階段，第一的話是手工階段，什麼東西都是手工搞。
第2個階段就是腳本階段了，本來手工搞的東西全部腳本化。
第3個階段就是平台化了，平台化了之後，所有東西都在頁面上完成系統完成，不需要人工來干預，甚至不用運維來搞。
有一些人說既然認為就是最後的一個階段，但是這個很不成熟。所以我就不說了。
針對你這個機器數少的，你可以手工認為，或者說用腳本認為都沒問題。
在合適的階段做合適的事情就是最好的。所以我建議你手工運維或者腳本運維。
我們項目用的 wgcloud運維監控系統 ，它前身是開源項目，後來推出的商業版，也有免費版
wgcloud運行很穩定，性能很好，部署和上手容易
wgcloud支持主機各種指標監控(cpu狀態/溫度，內存狀態，磁碟容量/IO，硬碟smart監控，系統負載，網卡流量，硬體系統信息等)，數據可視化，進程應用監控，大屏可視化，服務介面檢測，DOCKER監控，自動生成網路拓撲圖，埠監控，日誌文件監控，web SSH（堡壘機），指令下發執行，告警信息推送（郵件釘釘微信簡訊等）
可以裝虛擬機代替，在同一個區域網情況下
找服務商外包服務，或者網上託管也不貴收費
伺服器數量比較少，比如10台伺服器，基本可以不設置運維崗位了，後端開發人員 或者架構師就能搞定。
我就是那種曾經在創業的小公司待過的開發人員，開發，運維我都幹了。
但是想想如何更科學更高效的運維還是很有必要的。
軟體系統的運行時環境：即公司的業務產線，靠它創造業務價值，這個是最核心的功能訴求。
實時監控系統: 任何時候都要對當前公司的產線的壓力一清二楚，有問題功能隨時解決，有性能問題及時擴容或者回收資源
降低伺服器成本：在業務萎縮的情況下，准確評估哪些資源可以回收，降低伺服器的支出
這個是當時我認為的運維的三個主要目的。
運維方案開發半路出家，當時採用的是shell+python+ansible+jekins+elk的方式
首先，我會及時的更新業務產線的物理架構圖，根據架構圖來規劃伺服器的資源使用。
比如多少個web服務，資料庫多少，zk,kafka,redis集群怎麼分布。
集群部署一般是放在多個伺服器上的，這個時候ansible就派上用場了。
jekins主要用來自動發布更新程序已經做定時回收磁碟的任務。
elk主要用來做應用的日誌系統和監控告警； 可以通過看板隨時知道產線的請求數量和並發數量；
以上的運維方案適用於小公司。運維工程師看到了可以補充
搞個zabbix刷
數量少。如果配置好可以虛擬化。然後跑容器