[编程总结] 开源系统平台化建设思路
系统调研
- 用户视角的系统调研（只需使用）
- 平台视角的系统调研（需要进行系统的维护和二次开发）
平台侧系统调研
-
平台侧系统调研的原则
系统是动态发展的，而且许多系统开发迭代速度很快，所以基于某个固定版本去测试意义不是很大
测试环境的规模和测试场景有限，我们不可能测试出大规模集群下的性能瓶颈和扩展性问题，这只能依靠原理推导
只要我们理解了系统的架构，核心原理，我们就应该能够推测出其适用场景，固有缺陷，扩展性问题
-
平台侧系统调研的步骤
先通过系统官方文档，论文，公开资料，代码进行系统原理的调研，掌握系统的核心架构和原理
用该领域的标准测试集进行测试（比如OLAP领域的SSB和TPC-H测试）
二次测试：
标准测试集没有cover的场景
现有系统的痛点或者优势场景
原理上推测出的调研系统可能的痛点或者优势场景
原理上90%以上能够推测出结果的测试场景（无需测试） -
是否需要上线该系统：
运维管理成本
开发成本
社区的活跃度
业务需求的紧迫性
该系统离我们理想系统的距离和改造的成本
该系统在大规模集群下的可能瓶颈和问题
该系统的固有缺陷以及避免改缺陷的成本 -
平台侧调研需要注意的问题
如果调研的系统官方文档，论文，公开资料已经足够详细，我们就没有必要看代码；
即使必须要看代码，也不能限于代码海洋中，纠结某些细节问题，因为调研时间有限，不可能搞清所有细节问题；
看代码时，可以通过log，测试用例，debug 来加速我们对代码结构的整体理解和把握；
看代码时，尽可能带着明确的问题和线索去看
对于某些重要的技术细节，我们可以先掌握What和Why，对于How我们可以在业余时间或者真正需要使用到这种技术时再详细调研，因为某个技术细节不会影响我们对一个系统整体架构，核心原理和未来极限的理解
调研新系统时应该和已知系统进行对比，思考为什么不同系统在解决相同或者类似问题时采用了不同方案，不同方案之间的权衡是什么
用户侧系统调研：
目标系统在我们的需求场景下是否有成功案例
是否足够易用
性能和QPS是否能满足需求
是否可以提供SLA保证
平台运维
系统中坚决不能容许失败的运维操作我们都应该有重试机制和报警。
线上事故在处理前我们应该保留现场（log，jstack, jmap，监控截图等）
线上事故发生时的所有报警都有可能是有关联性的，无论报警是什么等级，我们都应该关注。
一个易维护系统的log必须是充足的，合理的，有意义的，人可读的；其中所有线程都应该有极具标志性的线程名。
稳定压倒一切，我们无法保证生产环境的稳定，我们就没法玩了。一个高可靠的系统源自可靠的系统设计，优秀的代码实现，充分的测试，可靠的运维，任何一个环节出现问题，都有可能导致事故的产生。
我们必须从事故处理，日常运维，日常客服这类工作中解脱出来，才会有更多精力满足我们用户更多的需求，才有可能打造一个高效，稳定，易用的平台。能解脱出来的前提是我们的系统是高可靠的，运维是自动化和高效的，我们的用户接入文档，使用文档，FAQ文档等是十分完善的，用户的对接和沟通过程应该是高度流程化和规范化的。
分布式系统必须考虑容错和局部失败；必须认为网络是不可靠的，物理时钟是不可靠的；有并发读写的场景就必须考虑分布式一致性问题。
开源系统落地需要做的事情
- 编译部署
- 监控报警
- 用户手册
- 核心性能指标收集和 Dashboard
- 公司周边系统集成
- 回归测试框架
- 大查询报警
- 自动化运维脚本
