公司内如何建设、管理分布式存储项目

 目录

现状&将来

引擎本身的管理

稳定性

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

时间管理

摄取技术信息

用户信息、用户运营

其他信息的获取

---

现状&将来

• 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信息同步、提问焦点的数据统计；找出触发频率高的问题，优先解决；做好交接；
  • 用户手册
    •  能力范围：明确告诉用户我们可以支持什么样的需求:API、功能、一些经典场景的性能

      • 引擎能提供什么服务，应该有一个列表，列入快照等，避免用户不知情，自己想了低效方案解决

      • 青藤不包含的流程，需要用户怎么做，找谁，提供什么信息

    • 适应场景的列表：good case

    • 不适合场景：bad case；什么样的不适合，不适合的可以找其他什么引擎（不能放用户不管）

• 定期进行用户回访

  • 用户可能比你更加了解你的服务（因为用户拥有持续的体验）；

  • 用户也在用其他的各种服务，他们对各种服务的的特性，以及特性的应用更加熟悉，可能为你带来一些建议和灵感；

  • 用户会反馈你的服务性能、易用性待提升的点（抓手）；

  • 对用户的每句话更加敏感，有时候只有一个用户提出的问题，或许有10个用户都遇到了；

  • 有时候用户只是简单说有点问题，但是可能已经造成了一定影响；

• 影响力：

  • 季度汇报：每个季度和业务同步一下各个引擎层面做了什么优化

  • 技术分享：分享会&文章

• 用户推广——主动寻找用户

  • 部门间的交流

  • 公司内部论坛文章

其他信息的获取

• 公司内部有哪些其他类似的引擎，和我们的引擎之间的区别是什么；我们的立脚点在哪里；

• 业界其他的解决方案：技术大会、论坛的论文；
• 技术分享；

• 开源社区：

  • 线上：定期关注社区发展，了解最新的Feature

    • 各个feature可能发展速度不一样，一些易用性方面的以及功能方面的可能应用速度比较快，比修改“核心”去提升性能的feature发展速度更快；可能易用性和功能的提升能比几毫秒的性能提升带来更多的用户；

  • 线下：关注社区发展，参与社区的活动，听各种讲座，论坛

    • 现场学习的效果与远程学习或者自己看社区jira的效果要好很多；

    • 大牛们会现场讲很多实际案例，可能是直接可以应用到自己团队的服务上的；

    • 现场交流；

    • “嫁接”经验：不能直接应用的案例、经验，也可能是可以“嫁接”或者参考的，可能和自己其他的方案组合起来，可以形成更好的策略；