本期專(zhuān)家：
姚 彬 優(yōu)維科技 系統架構師
林 鋒 浪潮商用機器企業(yè)云創(chuàng )新中心 華南區技術(shù)總監
任龍飛 紅帽企業(yè)級開(kāi)源解決方案中心 解決方案架構師
景顯強 紅帽企業(yè)級開(kāi)源解決方案中心 軟件架構設計師
劉 康 日志易 系統分析師
鐘錦鋅 SmartX超融合 產(chǎn)品經(jīng)理
李 寧 博云企業(yè)級PaaS及云管理解決方案中心 高級架構師
01 如何評估自動(dòng)化運維帶來(lái)的收益？
@姚彬 優(yōu)維科技 系統架構師：
運維核心職責是保證業(yè)務(wù)連續性，通常是花錢(qián)部門(mén)，建議量化圍繞這兩個(gè)方向：
1.業(yè)務(wù)：參考DevOps中四個(gè)核心指標，變更時(shí)長(cháng)、發(fā)布頻率、服務(wù)恢復時(shí)長(cháng)、變更失敗率。
2.投入：運維投入和業(yè)務(wù)量增長(cháng)的長(cháng)期曲線(xiàn)對比，短期不一定明顯。（資金、人員等）
02 運維自動(dòng)化的成功標志是什么？
@姚彬 優(yōu)維科技 系統架構師：
自動(dòng)化的基石是標準化，運維自動(dòng)化最直接的收益是效率和質(zhì)量的提升，工具化處理運維事物就是成功。
03 如何利用大數據提升云平臺自動(dòng)化運維管理能力？
@林鋒 浪潮商用機器企業(yè)云創(chuàng )新中心 華南區技術(shù)總監：
有同事在排查一些云平臺的問(wèn)題過(guò)程中，就碰到過(guò)日志極為瑣碎，出現了大量日常信息將故障關(guān)鍵信息掩蓋的過(guò)程，在日常維護、故障排查過(guò)程中，如何在大量日志中快速地找到故障關(guān)鍵字是個(gè)涉及大數據、人工智能的領(lǐng)域，這方面確實(shí)有待加強。
個(gè)人理解，利用大數據技術(shù)+人工智能，過(guò)濾日常常規信息應該是容易做到，而不常出現的信息應該是我們日常維護的關(guān)注點(diǎn)。目前業(yè)內已經(jīng)有多家從事智能運維的公司，可以提供支持Power、x86等多種異構云環(huán)境的智能運維平臺。
04 如何構建云計算場(chǎng)景下的自動(dòng)化運維系統？
@任龍飛 紅帽企業(yè)級開(kāi)源解決方案中心 解決方案架構師：
個(gè)人觀(guān)點(diǎn)，從現在的IT體系來(lái)看，從IaaS到SaaS, ansible工具已經(jīng)可以覆蓋大多數場(chǎng)景。今年RedHat/CoreOS開(kāi)源了Operator framework，針對容器領(lǐng)域的運維開(kāi)發(fā)框架，值得關(guān)注。
05 企業(yè)在控制風(fēng)險這塊應該如何控制自動(dòng)化運維與人為干涉的優(yōu)先級？
@景顯強 紅帽企業(yè)級開(kāi)源解決方案中心 軟件架構設計師：
腳本（playbook）自身的安全可靠性，需要進(jìn)行生產(chǎn)前的反復驗證。
上生產(chǎn)后，盡量依靠ansible tower這樣的管理平臺進(jìn)行ansible的執行，防止權限不匹配導致執行錯誤。
06 面對應用與應用之間復雜的依賴(lài)和調用關(guān)系，如何快速定位排查問(wèn)題？
@劉康 日志易 系統分析師：
這個(gè)問(wèn)題我們先倒推一下：
分析問(wèn)題需要什么？
分析問(wèn)題問(wèn)題肯定需要一些指標和數據，那么指標和數據該是哪些東西呢？指標和數據從哪里來(lái)呢？
指標肯定有系統層面也會(huì )有應用層面。但是通過(guò)指標一定能分析出問(wèn)題嗎？不一定，萬(wàn)一開(kāi)發(fā)就想寫(xiě)個(gè)bug玩呢？所以也得看下應用的日志。
如果需要分析依賴(lài)和調用，那就得下探針或者在日志中打出調用關(guān)系。
知道了需要哪些東西該怎么收集呢？
我們既要收集系統指標，又要收集應用指標，還需要收集應用日志。在進(jìn)行收集的時(shí)候我們不想消耗太多的資源。
收集完成怎么分析呢？
如果有了上面的數據只需要將我們的內容進(jìn)行適當的提取就可以進(jìn)行串聯(lián)分析。比如：
我通過(guò)日志發(fā)現在某一點(diǎn)交易失敗率高了，我只需要看一看此時(shí)系統層面的各個(gè)指標是否正常就可以迅速判斷出是否系統層面影響。再接著(zhù)我們只需要看看這個(gè)鏈路上的其他內容各個(gè)指標是否正常，可以快速判斷是哪個(gè)環(huán)節出問(wèn)題。
上面進(jìn)行完成了之后，再接著(zhù)分析應用的問(wèn)題，看一眼應用的運行指標情況，再看看日志，幾乎在一分鐘內就可以判斷故障出現在哪里。
甚至在進(jìn)一步可以做出實(shí)時(shí)告警。
上面那個(gè)方式在分布式環(huán)節尤其好使，因為運維人員不用去尋找是那一臺主機上的程序出現了問(wèn)題。
上面所說(shuō)的分析方式有哪些軟件呢？
開(kāi)源的：ELK
企業(yè)版：日志易、splunk
ELK：開(kāi)源，免費，但是需要較高的能力去維護（如果說(shuō)日志量每天幾個(gè)G那種忽略），DSL語(yǔ)句需要有一定的學(xué)習能力，搜索較慢。
日志易：操作簡(jiǎn)單，語(yǔ)句就是類(lèi)SQL。
splunk：美國的日志分析廠(chǎng)商。
07 在運維管理上，超融合架構的優(yōu)勢是什么？在超融合環(huán)境下，運維工作與傳統架構有什么不同？
@鐘錦鋅 SmartX超融合 產(chǎn)品經(jīng)理：
超融合架構在運維管理上的優(yōu)勢：
- 超融合省卻了原來(lái)集中式存儲的硬件管理以及 raid、mapping 等復雜的管理操作。
- 超融合硬件故障運維更加簡(jiǎn)單，硬盤(pán)故障無(wú)需熱備盤(pán)情況下，也可以自動(dòng)恢復，而且恢復速度遠高于傳統存儲。
- 虛擬化和存儲以及硬件管理都集中在統一界面上，管理員可以很輕松地發(fā)現各個(gè)組件的運行狀態(tài)。
- 在線(xiàn)擴展，自動(dòng)負載均衡功能，比起傳統架構擴容，減少了大量數據遷移甚至是避免了停機時(shí)間。
- 可以設置郵件報警或者通過(guò) SNMP 還有 restful api 與原有的監控中心進(jìn)行對接，實(shí)現智能監控管理。
在超融合環(huán)境下，運維工作的安排確實(shí)與傳統架構有所不同：
1、在傳統架構下，很多企業(yè)會(huì )安排專(zhuān)門(mén)的存儲管理員、虛擬化管理員；而在超融合環(huán)境下這兩者已經(jīng)合為一體，存儲和虛擬化實(shí)現統一界面管理，也省卻了原來(lái)集中式存儲硬件較為復雜的管理和運維。建議運維工作安排可以將存儲管理員和虛擬化管理員合并管理。
2、另外做得比較好的超融合平臺都有功能豐富的監控分析系統，并且可以支持通過(guò) SNMP 或者 API 集成到第三方監控平臺中進(jìn)行統一管理以及自動(dòng)報警等，這樣可以更有效地提升運維管理水平。
08 Docker的運維中需要關(guān)注的是什么？
@李寧 博云企業(yè)級PaaS及云管理解決方案中心 軟件架構設計師：
Docker運維過(guò)程中，整體而言需要關(guān)注三個(gè)方面：
- Docker集群的部署規模；按照目前來(lái)講，針對大規模的Docker集群，需要上層的調度系統做進(jìn)一步的管理（例如基于Kubernetes或者swarm），而且只有達到一定規模以后，才會(huì )重點(diǎn)關(guān)注配置優(yōu)化的參數（例如內部IP分配問(wèn)題，單個(gè)容器的資源消耗限制等）；
- Docker運行環(huán)境的穩定性，安全性，可靠性；需要做到Docker管理與運行業(yè)務(wù)容器達到友好兼容，管理節點(diǎn)正常與否，不應該影響運行業(yè)務(wù)容器，保證業(yè)務(wù)的正常對外輸出；考慮業(yè)務(wù)容器彼此的隔離性，防止安全入侵；Docker與監控告警系統，日志系統的對接和管理，能夠及時(shí)發(fā)現并處理運行過(guò)程中的問(wèn)題。
- 保證業(yè)務(wù)容器的正常穩定，因為所有的一切都是為業(yè)務(wù)服務(wù)的，業(yè)務(wù)正常穩定，才有意義。
歡迎企業(yè)IT領(lǐng)域原廠(chǎng)商入駐云社區。服務(wù)用戶(hù)，從解決用戶(hù)的日常問(wèn)題入手！來(lái)源：tlalkwithtrend
