一、業務背景
es服務當前沒有專門的部門負責維護和開發，交由各端自行負責維護，隨着公司業務查詢和統計需求非常多，會面臨居多方面問題和挑戰：
- 無人(專業RD或部門)負責
- 無專業的人進行維護，遇到問題幾乎無人處理
- 缺乏性能評估
- 查詢和統計相關語句執行無指標評價體系
- 運維效率較低
- 無操作友好且高效的web管理平台
- 質量評估缺失
- 監控報警體系不完善
- 缺乏運維體系建設
- 無集群性能評估和壓測報告
- 無容災容錯措施
- 無遷移擴容方案
- 無最佳實踐(容量、集群規模、jvm配置等等)
- 無優化方案
二、業務目標
- 提效率降成本，web自動化運維平台建設
- 優化性能，服務治理體系建設(SOP、調優)
- 集群性能評估，提供性能、壓測方案
- 保障質量，監控報警、數據報表完善和SLA
- 節約資源，進行集群規划和梳理，逐步收斂集群規模。 1.下線富余機器 2.相應機器降配置
- 新增安全性，新增鑒權模塊，實現訪問隔離和安全驗證
- 索引同步保證，保證數據一致性、正確性、實時性
三、技術規划
es成果落地分期進行，每期以季度為單位，每季度都要規划具體開發和落地任務以及完成時間
一期計划：
- 監控報警完善，報警考慮與第三方組件集成，例如運維體系、釘釘集成等
- 優化性能，集群性能調優、部署架構調整、集群分類。
- 建立各種SOP（安裝、機器配置、jvm配置、重啟、遷移、擴容等）
- 收斂集群規模和數量，下線富余機器。例如有的節點128G根本用不了，純屬浪費資源
- 測試方案，性能測試、功能測試、可靠性測試(各種容災容錯場景)、es版本升級與兼容性測試
二期計划：
- 建平台，推進web自動化運維平台建設
- 多集群管理(瀏覽、增減)
- 節點管理(瀏覽、增減)
- 業務接入評估公式和規范
- 業務申請入口
- 類SQL支持/統計查詢性能，集成官方SQL插件
三期計划：
- 架構升級優化，增加代理層
- 通過代理層檢索服務，實現限流，超時，重試機制
- 大集群業務訪問隔離
五、開發任務
人力需求規划：需求2人 一期計划 1人負責測試方案落地，容錯容災機制，保障集群穩定性 1人負責各種sop和演練，參與部分優化工作
參考資料
Elasticsearch壓測方案之esrally：
https://segmentfault.com/a/1190000011174694
演講：Pallas--唯品會統一檢索平台的演進和探索：
https://sz2018.archsummit.com/presentation/488
es高手博客
吃透Elasticsearch 堆內存：
https://blog.csdn.net/laoyang360/article/details/79998974
Elasticsearch聚合優化 | 聚合速度提升5倍：
https://blog.csdn.net/laoyang360/article/details/79253294
ElasticSearch學習筆記：
https://coyotey.gitbooks.io/elasticsearch
淺析ElasticSearch原理：
http://www.yunweipai.com/archives/24796.html