目录

现状&将来

引擎本身的管理

稳定性

性能:性能上如何做到优于社区

时间管理

摄取技术信息

用户信息、用户运营

其他信息的获取


现状&将来

  • P99
  • 平响
  • Java-Gc
  • compact
  • 事务
  • 故障恢复时间
  • 集群瓶颈:
  • 元数据管理
  • 单机承载能力
  • 相关重要组件
  • 底层存储

以下内容仅限于个人经验和个人接收的信息,持续补充中;

我们能做什么

引擎本身的管理

稳定性

  • 正确性:数据不丢失;无逻辑错误;
  • 健壮性:让用户怎么配置,怎么使用,都不会对引擎造成影响;
  • case:
  • 限流
  • 热点数据/操作的处理;
  • 中心节点,元数据做到压力;
  • compact,split,flush对集群有什么影响
  • 深入源码了解机制,拒绝只看技术博客;思考如果用户请求量是现在的10、100倍会发生什么;
  • 对引擎的“把握”:源码的掌握是必须的,另外对引擎的全链路监控也十分重要,除了问题需要能快速分析出问题点;这样才能:1.快速解决问题;2.了解引擎状态的上下文,有利于后面优化工作;

性能:性能上如何做到优于社区

  • 毛刺问题:分析线上case;形成处理毛刺问题的通用解决方案;
  • 平响:
  • 可运维性:MTTR,MTTF
  • 各种需要运维触发的操作,是否可以通过引擎自动触发;
  • 透明度:
  • 运维操作做到基本不影响用户——优化、管理员可以更轻松的进行新特性的应用;
  • 动态加载参数:为了增强稳定性和性能,我们可能需要进行很多的开发和线上变更,变更期间可能会对用户产生影响;是否可以动态加载配置;
  • 主备切换做到不需要用户关注;
  • 我们对引擎的把控:
  • 用户的所有操作管理员都可控:比如snapshot,restore_snapshot[审计日志]
  • 引擎的每个模块应该都有监控指标可观察,覆盖整个请求链路
  • memstore,bucketCache,HDFS
  • ThriftServer——采集metric,增加了审计日志
  • 遇到问题,分析数据,拉出集群整体数据,找通用的解决方案;并且解决方案能做到对用户友好;而不是每个case临时处理、手动处理、影响用户体验;
  • Quota
  • 多思考用户为什么使用我们服务,而不是自己搭建一个服务的理由(我们需要做得比社区做的更好,然后回馈社区)
  • 学习其他各种引擎的改进、原生的优点;横向对比;不要介意拿来主义;

时间管理

  • 如何减少事务性工作,将时间腾出到内核研发本身:
  • 形成提高引擎能力,到减少问题的正向循环;不要造成引擎管理模糊
  • 减少用户沟通成本:
  • 适当更多的开放监控给用户[TODO:如何限权限]
  • 完整的用户手册[提高70%的效率]
  • 用户对表的需求,更多开放给用户自己触发/放入流程中
  • 给用户提供优化建议/解决方案的时候,有条理,直接列出1,2,3;
  • 减少团队内部沟通成本:
  • 基础信息形成文档规范、工具
  • 信息同步及时、方便查找:值班交接信息应该在上一个onCall结束之前完成;代码的commit信息清晰,可追溯;
  • onCall日志,交接,数据分析统计,改进方案;onCall的意义在于让问题逐渐减少,大部分问题能以后不再人工处理,而不是每次去处理同样的问题;

摄取技术信息

用户信息、用户运营

  • 日常对接用户
  • 用户有问题都使用大群:避免多个用户反复提同一个问题;
  • 建立服务号机制:onCall信息同步、提问焦点的数据统计;找出触发频率高的问题,优先解决;做好交接;
  • 用户手册
  • 引擎能提供什么服务,应该有一个列表,列入快照等,避免用户不知情,自己想了低效方案解决
  • 青藤不包含的流程,需要用户怎么做,找谁,提供什么信息
  • 适应场景的列表:good case
  • 不适合场景:bad case;什么样的不适合,不适合的可以找其他什么引擎(不能放用户不管)
  • 定期进行用户回访
  • 用户可能比你更加了解你的服务(因为用户拥有持续的体验);
  • 用户也在用其他的各种服务,他们对各种服务的的特性,以及特性的应用更加熟悉,可能为你带来一些建议和灵感;
  • 用户会反馈你的服务性能、易用性待提升的点(抓手);
  • 对用户的每句话更加敏感,有时候只有一个用户提出的问题,或许有10个用户都遇到了;
  • 有时候用户只是简单说有点问题,但是可能已经造成了一定影响;
  • 影响力:
  • 季度汇报:每个季度和业务同步一下各个引擎层面做了什么优化
  • 技术分享:分享会&文章
  • 用户推广——主动寻找用户
  • 部门间的交流
  • 公司内部论坛文章

其他信息的获取

  • 公司内部有哪些其他类似的引擎,和我们的引擎之间的区别是什么;我们的立脚点在哪里;
  • 业界其他的解决方案:技术大会、论坛的论文;
  • 技术分享;
  • 开源社区:
  • 线上:定期关注社区发展,了解最新的Feature
  • 各个feature可能发展速度不一样,一些易用性方面的以及功能方面的可能应用速度比较快,比修改“核心”去提升性能的feature发展速度更快;可能易用性和功能的提升能比几毫秒的性能提升带来更多的用户;
  • 线下:关注社区发展,参与社区的活动,听各种讲座,论坛
  • 现场学习的效果与远程学习或者自己看社区jira的效果要好很多;
  • 大牛们会现场讲很多实际案例,可能是直接可以应用到自己团队的服务上的;
  • 现场交流;
  • “嫁接”经验:不能直接应用的案例、经验,也可能是可以“嫁接”或者参考的,可能和自己其他的方案组合起来,可以形成更好的策略;