今天分享專題大綱如圖所示，從5個(gè)方面跟大家一起探討:
1、點(diǎn)評(píng)運(yùn)維團(tuán)隊(duì)的配置
目前我們運(yùn)維分為4個(gè)組，相信跟大部分公司一樣，運(yùn)維團(tuán)隊(duì)分為：應(yīng)用運(yùn)維、系統(tǒng)運(yùn)維、運(yùn)維開發(fā)和監(jiān)控運(yùn)維，當(dāng)然還有DBA團(tuán)隊(duì)和安全團(tuán)隊(duì)，這里就不一一羅列了。整個(gè)運(yùn)維團(tuán)隊(duì)全算上目前是不到40人規(guī)模。
我們團(tuán)隊(duì)分工是這樣的：
應(yīng)用運(yùn)維：負(fù)責(zé)支持線上業(yè)務(wù)，各自會(huì)負(fù)責(zé)對(duì)應(yīng)的業(yè)務(wù)線，主要職能是保證線上業(yè)務(wù)穩(wěn)定性和同開發(fā)共同支撐對(duì)應(yīng)業(yè)務(wù)，以及線上服務(wù)管理和持續(xù)優(yōu)化。
運(yùn)維開發(fā)：幫助運(yùn)維提升工作效率，開發(fā)方便快捷的工具，實(shí)現(xiàn)運(yùn)維平臺(tái)化自動(dòng)化。
系統(tǒng)運(yùn)維：負(fù)責(zé)操作系統(tǒng)定制和優(yōu)化，IDC管理和機(jī)器交付，以及跳板機(jī)和賬號(hào)信息管理。
監(jiān)控運(yùn)維：負(fù)責(zé)發(fā)現(xiàn)故障，并第一時(shí)間通知相關(guān)人員，及時(shí)處理簡(jiǎn)單故障和啟動(dòng)降級(jí)方案等。
2、點(diǎn)評(píng)的整體架構(gòu)
先看下點(diǎn)評(píng)的機(jī)房情況。
點(diǎn)評(píng)目前是雙機(jī)房結(jié)構(gòu)，A機(jī)房主跑線上業(yè)務(wù)，B機(jī)房跑測(cè)試環(huán)境和大數(shù)據(jù)處理作業(yè)，有hadoop集群、日志備份、災(zāi)備降級(jí)應(yīng)用（在建）等。點(diǎn)評(píng)目前機(jī)房物理機(jī)+虛擬機(jī)有近萬臺(tái)機(jī)器。
點(diǎn)評(píng)的整體架構(gòu)，還是跟多數(shù)換聯(lián)網(wǎng)公司一樣，采用多級(jí)分層模式，我們繼續(xù)來詳細(xì)看下點(diǎn)評(píng)整體架構(gòu)。
上面這幅圖基本概括了點(diǎn)評(píng)的整體架構(gòu)環(huán)境：
用戶引導(dǎo)層用的是第三方的智能DNS+CDN。
負(fù)載均衡首先是F5做的4層負(fù)載均衡 之后是dengine做的7層負(fù)載均衡（Dengine是在tengine基礎(chǔ)上做了二次開發(fā)）。再往后是varnish做的頁面緩存 之后請(qǐng)求到web端 web端通過內(nèi)部協(xié)議調(diào)用service（RPC）。
圖片存儲(chǔ)用的是mogileFS分布式存儲(chǔ) 。
所有業(yè)務(wù)，全部有高可用方案，應(yīng)用全部是至少2臺(tái)以上。
當(dāng)然，具體業(yè)務(wù)要復(fù)雜很多，這里只是抽象出簡(jiǎn)單層面，方便各位同學(xué)理解。
目前，點(diǎn)評(píng)運(yùn)維監(jiān)控是從4個(gè)維度來做的：
業(yè)務(wù)層面，如團(tuán)購業(yè)務(wù)每秒訪問數(shù)，團(tuán)購券每秒驗(yàn)券數(shù)，每分鐘支付、創(chuàng)建訂單等（cat）。
應(yīng)用層面，每個(gè)應(yīng)用的錯(cuò)誤數(shù)，調(diào)用過程，訪問的平均耗時(shí)，最大耗時(shí)，95線等（cat）。
系統(tǒng)資源層面：如cpu、內(nèi)存、swap、磁盤、load、主進(jìn)程存活等 （zabbix）。
網(wǎng)絡(luò)層面： 如丟包、ping存活、流量、tcp連接數(shù)等（zabbix cat）。
3、點(diǎn)評(píng)運(yùn)維系統(tǒng)介紹
點(diǎn)評(píng)的運(yùn)維和平臺(tái)架構(gòu)組做了很多實(shí)用的工具，這些工具組成了點(diǎn)評(píng)的整體運(yùn)維體系。
目前自動(dòng)化運(yùn)維比較熱，但自動(dòng)化運(yùn)維個(gè)人覺得是一種指導(dǎo)思想，沒必要硬造概念和生搬硬套。自動(dòng)化在很多公司百花齊放，各家有各家的玩法。但不管怎么定義，運(yùn)維人員都必須從不同緯度去面對(duì)和解決企業(yè)所存在的問題。
點(diǎn)評(píng)在這方面，也是摸著石頭過河，我們的思路是先造零件，再整合，通過零件的打造和之間的整合，慢慢勾勒出一條適合自己的運(yùn)維自動(dòng)化框架。
我們運(yùn)維的理念是：
能用程序干活的，堅(jiān)決程序化、平臺(tái)化；
能用管理解決的問題，不用技術(shù)解決；
同一個(gè)錯(cuò)誤不能犯三次；
每次故障，都是學(xué)習(xí)和提升的機(jī)會(huì)；
每個(gè)人都要有產(chǎn)品化思維，做平臺(tái)產(chǎn)品讓開發(fā)走自助路線；
小的，單一的功能，組合起來完成復(fù)雜的操作（任務(wù)分解）；
所以，我們將自己的理念，融入到自己的作品中，做出了很多工具。
首先整體做個(gè)說明，點(diǎn)評(píng)運(yùn)維工具系統(tǒng)匯總：
全方位監(jiān)控系統(tǒng)：覆蓋業(yè)務(wù)、應(yīng)用、網(wǎng)絡(luò)、系統(tǒng)等方面，做到任何問題，都可直觀反饋。對(duì)不同應(yīng)用等級(jí)，做到不同監(jiān)控策略和報(bào)警策略。
自動(dòng)化工具系統(tǒng)：對(duì)重復(fù)的、容易出錯(cuò)的、繁瑣的工作盡可能工具化，通過小的策略組合，完成大的任務(wù)。
配置和管理系統(tǒng)：對(duì)于復(fù)雜的配置管理，盡可能web化、標(biāo)準(zhǔn)化、簡(jiǎn)單化，有模板定義，有規(guī)范遵循。
記錄和分析系統(tǒng)：對(duì)發(fā)生的問題和數(shù)據(jù)做記錄并分析，不斷的總結(jié)、完善和提升。
下面就跟大家來一一介紹下:
3.1 全方位監(jiān)控系統(tǒng)
Zabbix大家應(yīng)該非常熟悉了，這里就不做介紹，主要介紹下cat監(jiān)控。
這張是cat的應(yīng)用監(jiān)控圖表，可直觀從業(yè)務(wù)角度看出問題，可跟基線的對(duì)比，發(fā)現(xiàn)問題所在。如圖所示，此時(shí)支付遠(yuǎn)偏離基線，流量正常，可能后端出了問題。
除了這些，還有創(chuàng)建訂單、支付、首頁訪問、手機(jī)訪問等業(yè)務(wù)數(shù)據(jù)。
這張圖是從業(yè)務(wù)角度來監(jiān)控的。
這張也是從業(yè)務(wù)層面來監(jiān)控的，該圖展示的是手機(jī)的訪問量趨勢(shì)圖，下面包括延遲、成功率、鏈接類型、運(yùn)營商等都有明確數(shù)據(jù)，該監(jiān)控可全方位覆蓋業(yè)務(wù)。
從業(yè)務(wù)層面往下，就是應(yīng)用層面。
應(yīng)用狀態(tài)大盤可清晰表示當(dāng)前業(yè)務(wù)組件狀態(tài)，如果某個(gè)業(yè)務(wù)不可用，其下面某個(gè)應(yīng)用大量報(bào)錯(cuò)，說明可能是該應(yīng)用導(dǎo)致。
該監(jiān)控大盤十分清晰明的能展示業(yè)務(wù)下面的應(yīng)用狀態(tài)，可在某業(yè)務(wù)或者某域名打不開的時(shí)候，第一時(shí)間找出源頭。
下圖為應(yīng)用報(bào)錯(cuò)大盤，出問題的應(yīng)用會(huì)實(shí)時(shí)登榜（每秒都會(huì)刷新數(shù)據(jù)），當(dāng)出現(xiàn)大故障時(shí)，運(yùn)維人員可一眼看出問題；而當(dāng)多個(gè)不同業(yè)務(wù)同時(shí)報(bào)錯(cuò)時(shí)，則可能是公共基礎(chǔ)服務(wù)出了問題。
再看下圖的這個(gè)功能，是Cat最強(qiáng)大的功能，能完整顯示應(yīng)用之間調(diào)用過程，做了什么事情，請(qǐng)求了那些，用了多長時(shí)間，成功率是多少，訪問量是多大，盡收眼底。 Cat幾乎無死角的覆蓋到業(yè)務(wù)和應(yīng)用層面的監(jiān)控，當(dāng)然還可做網(wǎng)絡(luò)等層面監(jiān)控，總之非常強(qiáng)大。這也是點(diǎn)評(píng)的鷹眼系統(tǒng)。
Logscan系統(tǒng)，是一套日志掃描工具，可根據(jù)你定義的策略，對(duì)日志內(nèi)容進(jìn)行定時(shí)掃描，該工具可覆蓋到基于日志內(nèi)容的檢測(cè)，結(jié)合zabbix和cat，實(shí)現(xiàn)無死角覆蓋。 比如有一些攻擊的請(qǐng)求，一直遍歷你的url，通過cat、zabbix等都無法靈活捕獲，有了日志掃描，便可輕松發(fā)現(xiàn)。
3.2 自動(dòng)化工作系統(tǒng)
首先介紹下點(diǎn)評(píng)的流程系統(tǒng)-workflow系統(tǒng)
顧名思義workflow是一套流程系統(tǒng)，其核心思想是把線上所有的變更以標(biāo)準(zhǔn)化流程的方式，梳理出來。
我們遵循一個(gè)理念，能用程序跑，就不去人操作。
流程有不同狀態(tài)的轉(zhuǎn)化，分別為發(fā)起、審計(jì)、執(zhí)行、驗(yàn)證等環(huán)節(jié)。用戶可自行發(fā)起自己的需求變更，通過運(yùn)維審核，操作（大部分是自動(dòng)的），驗(yàn)證。 如擴(kuò)容、上線、dump內(nèi)存、封IP等都為自動(dòng)化流程。
以我們線上自動(dòng)化擴(kuò)容流程為展示，用戶使用時(shí)，需要填寫對(duì)應(yīng)信息，提交后，運(yùn)維在后臺(tái)審核過后，就完全自動(dòng)化擴(kuò)容，擴(kuò)容完成會(huì)有郵件通知，全程運(yùn)維不需要登錄服務(wù)器操作。（自動(dòng)化倒不是太復(fù)雜的技術(shù)難題，通過小的任務(wù)組合，設(shè)置好策略即可）. 幾十臺(tái)機(jī)器的擴(kuò)容，運(yùn)維只需點(diǎn)個(gè)審核通過按鈕，數(shù)分鐘而已。
經(jīng)過長時(shí)間的推廣，點(diǎn)評(píng)現(xiàn)在98%以上變更都是通過工作流平臺(tái)完成的，所有變更全部有記錄，做到出問題時(shí) 有法可依，違法可糾。
而且通過流程單的使用頻率，可做數(shù)據(jù)分析，了解哪些操作比較頻繁，能否自動(dòng)化掉，是否還有優(yōu)化空間。 這才是做平臺(tái)的意義，以用戶為導(dǎo)向。
流程系統(tǒng)就介紹到這里，朋友們可關(guān)注下其中核心思想。
下面介紹另一套重量級(jí)核心系統(tǒng)：Button系統(tǒng)
Button是一套代碼管理、打包、部署上線系統(tǒng)，開發(fā)可完全自主化進(jìn)行上傳代碼，自動(dòng)化測(cè)試，打包，預(yù)發(fā)，灰度上線，全部上線，問題回滾等操作。 全程運(yùn)維不用干預(yù)，完全平臺(tái)自主化。
點(diǎn)評(píng)的運(yùn)維，除了有些沒法自動(dòng)化的手動(dòng)配置下，其他基本都是開發(fā)自助。 這就是自動(dòng)化的威力！
Go平臺(tái)系統(tǒng)，是一套運(yùn)維操作系統(tǒng)，其中包含了很多常規(guī)操作、如批量重啟、降級(jí)、切換、上下線、狀態(tài)檢測(cè)等。
該系統(tǒng)主要是解決運(yùn)維水平參差不齊，工具又各有各的用法，比如說批量重啟操作，有用ssh、有用fabric、有自己寫shell腳本的。 干脆直接統(tǒng)一，進(jìn)行規(guī)范，定義出來操作，通過平臺(tái)化進(jìn)行標(biāo)準(zhǔn)化。 由于長時(shí)間不出問題，偶爾出一下，運(yùn)維長時(shí)間不操作，找個(gè)批量重啟腳本還要找半天。 哪些不能自動(dòng)化的，我們基本都做到go里了，在這里基本都是一鍵式的傻瓜操作了。
現(xiàn)在，我們監(jiān)控團(tuán)隊(duì)就可以靈活操作，不需要有多高的技術(shù)含量，并且每次操作都有記錄，做好審計(jì)和授權(quán)。
所有后臺(tái)基本都是python、shell腳本實(shí)現(xiàn)，小的腳本組再整合成任務(wù)，這也是我們的重要理念之一。 對(duì)于比較復(fù)雜的任務(wù)，我們進(jìn)行分解，然后用小的，單一的功能，組合起來完成復(fù)雜的操作（任務(wù)分解）。 其實(shí)我們實(shí)現(xiàn)自動(dòng)化也是這個(gè)思路，先造零件，再拼裝。
盡管有了puppet，go等工具，但對(duì)于一些job作業(yè)的管理，也顯得非常吃力，我們架構(gòu)組的同學(xué)做出一套任務(wù)調(diào)度系統(tǒng)。相當(dāng)于分布式的crontab，并且有強(qiáng)大的管理端。 完全自主化管理，只需要定義你需要跑的job，你的策略，就完全不用管了。會(huì)自動(dòng)去做，并且狀態(tài)匯報(bào)、監(jiān)控、等等全部都有記錄，并實(shí)現(xiàn)完全自助化。
以上這些系統(tǒng)都非常注重體驗(yàn)，都有非常詳細(xì)的數(shù)據(jù)統(tǒng)計(jì)和分析，每過一段時(shí)間，都有人去看，不斷改進(jìn)和優(yōu)化，真正做到產(chǎn)品自運(yùn)營。還有一些自動(dòng)化系統(tǒng)就不一一介紹了。
3.3 配置和管理系統(tǒng)
先介紹下puppet管理系統(tǒng)，相信不少同學(xué)對(duì)puppet語法格式深惡痛絕，并且也領(lǐng)教過一旦改錯(cuò)造成的故障嚴(yán)重性。
而且隨著多人協(xié)同工作后，模板和文件命名千奇百怪，無法識(shí)別。
針對(duì)這些問題，點(diǎn)評(píng)就做了一套管理工具，主要是針對(duì)puppet語法進(jìn)行解析，實(shí)現(xiàn)web化管理，并進(jìn)行規(guī)范化約束。
跟go系統(tǒng)一樣的想法，將puppet中模塊進(jìn)行組合，組合成模塊集（方法集），可方便識(shí)別和靈活管理。
下面展示的是我們的軟負(fù)載均衡管理頁面，該系統(tǒng)是線上SLB的管理系統(tǒng)。 其核心在于把nginx語法通過xml進(jìn)行解析，實(shí)現(xiàn)web化管理，傻瓜式配置，規(guī)范化配置，避免誤操作，版本控制，故障回滾等。
點(diǎn)評(píng)系統(tǒng)很多，基本上遇到個(gè)痛點(diǎn)，都會(huì)有人想辦法把痛點(diǎn)解決。
下面就介紹下點(diǎn)評(píng)另一套強(qiáng)大配置系統(tǒng)，lion。
Lion是一套應(yīng)用配置管理系統(tǒng)，點(diǎn)評(píng)的所有應(yīng)用用到的配置，不在本地文本文件存儲(chǔ)，都在一個(gè)單獨(dú)系統(tǒng)存儲(chǔ)，存儲(chǔ)以key/value的方式存儲(chǔ)。并且也是完全平臺(tái)化，運(yùn)維負(fù)責(zé)做好權(quán)限控制和審計(jì)。開發(fā)全部自助。
其核心是用了zookeeper的管理機(jī)制，將配置信息保存在 Zookeeper 的某個(gè)目錄節(jié)點(diǎn)中，然后將所有需要修改的應(yīng)用機(jī)器監(jiān)控配置信息的狀態(tài)，一旦配置信息發(fā)生變化，每臺(tái)應(yīng)用機(jī)器就會(huì)收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置信息應(yīng)用到系統(tǒng)中。
是不是在點(diǎn)評(píng)做運(yùn)維輕松很多？各種操作都工具化，自助化，自動(dòng)化了。那運(yùn)維還需要做什么。
3.4 記錄和分析系統(tǒng)
此類系統(tǒng)雖然不怎么起眼，但對(duì)我們幫助也是特別大的，我們通過一些系統(tǒng)的數(shù)據(jù)記錄和分析，發(fā)現(xiàn)了不少問題，也解決不少潛在問題，更重要的是，在這個(gè)不斷完善總結(jié)的過程中，學(xué)習(xí)到了很多東西。
這個(gè)是我們故障分析系統(tǒng)，所有的故障都會(huì)做記錄，故障結(jié)束后都會(huì)case by case的進(jìn)行深入分析和總結(jié)。其實(shí)以上很多系統(tǒng)，都是從這些記錄中總結(jié)出來的。
該系統(tǒng)為故障記錄系統(tǒng)，每個(gè)故障都有發(fā)生的緣由和改進(jìn)的方案，定期有人review。
運(yùn)維起來很輕松嗎？也不輕松，只是工作重點(diǎn)有了轉(zhuǎn)移，避開了那些重復(fù)繁瑣的工作，和開發(fā)同學(xué)深度結(jié)合，共同注重運(yùn)營質(zhì)量和持續(xù)優(yōu)化。
再來看下圖所示是點(diǎn)評(píng)的DOM系統(tǒng)，即運(yùn)營質(zhì)量管理平臺(tái)，該平臺(tái)匯總了線上的服務(wù)器狀態(tài)、應(yīng)用響應(yīng)質(zhì)量、資源利用率、業(yè)務(wù)故障等全方位的數(shù)據(jù)匯總平臺(tái)。
并通過同比和環(huán)比，以及平均指標(biāo)等數(shù)據(jù)，讓各開發(fā)團(tuán)隊(duì)進(jìn)行平臺(tái)化PK，性能差的運(yùn)維會(huì)去推動(dòng)改進(jìn)。
最后一個(gè)需要介紹的是雷達(dá)系統(tǒng)，該系統(tǒng)是我們最近在做的，一個(gè)比較高大上的項(xiàng)目。
朋友們也感受到了，我們系統(tǒng)之多，出問題查起來也比較費(fèi)時(shí)。 不少同學(xué)生產(chǎn)環(huán)節(jié)也遇到過類似問題，出了問題到底是什么鬼？到底哪一塊引起的呢？ 結(jié)合這個(gè)問題，我們把線上的問題做了個(gè)分類，并給了一些策略層面的算法，能快速顯示。 可讓故障有個(gè)上下文的聯(lián)系，如：上線時(shí)間、請(qǐng)求數(shù)下降、錯(cuò)誤數(shù)增多等，哪個(gè)先出現(xiàn)，哪個(gè)后出現(xiàn)？ 當(dāng)然，這塊功能還在做，目標(biāo)是實(shí)現(xiàn) 出問題的時(shí)候，一眼就能從雷達(dá)系統(tǒng)定位問題類型和范圍。
以上向大家演示的就是點(diǎn)評(píng)的運(yùn)維系統(tǒng)，相信我們點(diǎn)評(píng)的運(yùn)維思想都在里面體現(xiàn)了。
運(yùn)維點(diǎn)評(píng)這幾年的發(fā)展，主要目標(biāo)是實(shí)現(xiàn)平臺(tái)規(guī)范化、運(yùn)維高效化、開發(fā)自主化 。
之前也是通過運(yùn)維root登錄，然后寫腳本批量跑命令的低效運(yùn)維。也經(jīng)歷過CMDB系統(tǒng)信息不準(zhǔn)確，上線信息錯(cuò)亂的尷尬局面。也遇到過出了很大問題，運(yùn)維忙來忙去，找不到rootcase。
好在，通過努力，這些問題現(xiàn)在都有了很大改觀，相信朋友們通過展示的系統(tǒng)，能感覺出點(diǎn)評(píng)運(yùn)維的進(jìn)步。
4、運(yùn)維踩過的坑和改進(jìn)的地方
我就這些年，點(diǎn)評(píng)運(yùn)維出的一些case案例，跟大家聊一聊我們做了哪些具體工作:
變更不知道誰做的，無法恢復(fù)，變更完也找不到根據(jù)，造成重大故障。//之前線上puppet通過vim的管理方式，由于運(yùn)維同學(xué)失誤推了一個(gè)錯(cuò)誤配置，導(dǎo)致全部業(yè)務(wù)不可用1個(gè)小時(shí)，我們后面通過規(guī)范puppet配置修改并做成工具，進(jìn)行權(quán)限控制，還加了流程系統(tǒng)，進(jìn)行避免。
出了問題，開發(fā)說代碼沒問題，運(yùn)維說環(huán)境沒問題，該找誰？//我們后面做了工具，通過DOM和cat系統(tǒng)，可進(jìn)行深度診斷，基本很容易定位問題所屬。
執(zhí)行了個(gè)錯(cuò)誤命令，全線都變更了，導(dǎo)致服務(wù)不可用。//我們通過go系統(tǒng)，進(jìn)行日常操作梳理，并做成工具，運(yùn)維90%操作都可通過自動(dòng)化流程和go平臺(tái)完成。大大縮減故障產(chǎn)生率，并且之后進(jìn)行權(quán)限回收。
出問題了，各種系統(tǒng)翻來查去，無法快速定位，找不到rootcase。//點(diǎn)評(píng)正在做雷達(dá)系統(tǒng)，就是將歷史存在的問題，進(jìn)行復(fù)盤，將一些故障類型，進(jìn)行分級(jí)，然后通過策略和算法，在雷達(dá)系統(tǒng)上進(jìn)行掃描，出問題環(huán)節(jié)可快速第一時(shí)間優(yōu)先顯示。
運(yùn)維天天忙成狗，還不出成績，天天被開發(fā)吐槽。//點(diǎn)評(píng)這兩年完全扭轉(zhuǎn)了局勢(shì)，現(xiàn)在是運(yùn)維吊打開發(fā)，因?yàn)槲覀兡壳?，大部分系統(tǒng)都實(shí)現(xiàn)了開發(fā)自助化，運(yùn)維被解放出來，開始不斷完善平臺(tái)和關(guān)注業(yè)務(wù)運(yùn)營質(zhì)量，我們dom系統(tǒng)是可定制的，運(yùn)維每天都把各業(yè)務(wù)的核心指標(biāo)報(bào)表發(fā)到各位老大那里，哪些服務(wù)質(zhì)量差，響應(yīng)慢，開發(fā)都會(huì)立即去改。（當(dāng)然，需要老大們支持）。
5、未來關(guān)注的領(lǐng)域和方向
點(diǎn)評(píng)也有些前沿的關(guān)注點(diǎn)，比如比較熱的Paas技術(shù)。
PaaS和云很熱，還有docker技術(shù)，點(diǎn)評(píng)也不能掉隊(duì)，目前點(diǎn)評(píng)有數(shù)千個(gè)docker的實(shí)例在跑線上的業(yè)務(wù)。
上圖java都是跑的docker實(shí)例
目前點(diǎn)評(píng)Docker這塊可做到10秒內(nèi)快速部署業(yè)務(wù)并可響應(yīng)用戶請(qǐng)求。30秒內(nèi)可完成一次實(shí)例無縫遷移。 個(gè)人感覺docker技術(shù)不在于底層這塊，在于上層管理系統(tǒng)的構(gòu)造。底層一方面是持續(xù)優(yōu)化，挖掘性能，但更重要的是在策略層和調(diào)度層。 如何快速部署、遷移、恢復(fù)、降級(jí)、擴(kuò)容等，做好這些還有不少挑戰(zhàn)。
點(diǎn)評(píng)這兩年成長很多，但需要走的路也很多，未來關(guān)注的點(diǎn)會(huì)在多系統(tǒng)的有機(jī)整合和新技術(shù)的嘗試以及發(fā)展，還會(huì)更多的關(guān)注智能策略層面。
