一、业务背景
es服务当前没有专门的部门负责维护和开发，交由各端自行负责维护，随着公司业务查询和统计需求非常多，会面临居多方面问题和挑战：
- 无人(专业RD或部门)负责
- 无专业的人进行维护，遇到问题几乎无人处理
- 缺乏性能评估
- 查询和统计相关语句执行无指标评价体系
- 运维效率较低
- 无操作友好且高效的web管理平台
- 质量评估缺失
- 监控报警体系不完善
- 缺乏运维体系建设
- 无集群性能评估和压测报告
- 无容灾容错措施
- 无迁移扩容方案
- 无最佳实践(容量、集群规模、jvm配置等等)
- 无优化方案
二、业务目标
- 提效率降成本，web自动化运维平台建设
- 优化性能，服务治理体系建设(SOP、调优)
- 集群性能评估，提供性能、压测方案
- 保障质量，监控报警、数据报表完善和SLA
- 节约资源，进行集群规划和梳理，逐步收敛集群规模。 1.下线富余机器 2.相应机器降配置
- 新增安全性，新增鉴权模块，实现访问隔离和安全验证
- 索引同步保证，保证数据一致性、正确性、实时性
三、技术规划
es成果落地分期进行，每期以季度为单位，每季度都要规划具体开发和落地任务以及完成时间
一期计划：
- 监控报警完善，报警考虑与第三方组件集成，例如运维体系、钉钉集成等
- 优化性能，集群性能调优、部署架构调整、集群分类。
- 建立各种SOP（安装、机器配置、jvm配置、重启、迁移、扩容等）
- 收敛集群规模和数量，下线富余机器。例如有的节点128G根本用不了，纯属浪费资源
- 测试方案，性能测试、功能测试、可靠性测试(各种容灾容错场景)、es版本升级与兼容性测试
二期计划：
- 建平台，推进web自动化运维平台建设
- 多集群管理(浏览、增减)
- 节点管理(浏览、增减)
- 业务接入评估公式和规范
- 业务申请入口
- 类SQL支持/统计查询性能，集成官方SQL插件
三期计划：
- 架构升级优化，增加代理层
- 通过代理层检索服务，实现限流，超时，重试机制
- 大集群业务访问隔离
五、开发任务
人力需求规划：需求2人 一期计划 1人负责测试方案落地，容错容灾机制，保障集群稳定性 1人负责各种sop和演练，参与部分优化工作
引用博客地址：https://www.cnblogs.com/lizherui/p/12769878.html
