15-06-12

现象一： 6月6号服务中断问题，技术总监应该对引入新框架或新技术后，给平台带来的以下共性问题进行充分评估：
1. 解决或优化现有的什么问题
2. 带来哪些向下兼容性问题，（优美的）解决这些问题的方案
3. 新特性对平台带来了哪些问题隐患（这些隐患不一定要立即处理，但是至少要心中有数）
4. 引入新特性时如何保持平台的扩展性

现象二：请看以下changelog：

3.1.2.4 发布日期：2015-06-11
取消将标准 UTC 时间自动换换为本地时间
3.1.2.3 发布日期：2015-06-10
将服务端返回的标准 UTC 时间自动转换成本地时间

这是在一位用户对3.1.2.3的变更提出抗议后，iOS工程师立即发布了3.1.2.4的变更

LeanCloud是一个跨平台的SDK，产品总监应该对任何一个功能变更或功能引入进行以下评估：
1. 解决或优化现有的什么问题，这些问题是单平台还是多平台问题
2. 对本平台带来哪些向下兼容性问题，对其它平台会造成哪些影响
3. 其它平台是否能支持这些特性，其它平台引入这些特性后，会产生什么隐患
4. 引入新特性时如何保持整体的扩展性（而不是iOS、Android、H5自己开发自己的）

以上内容可能有点虚，就拿UTC这个问题来说。

新特性：将服务端返回的标准 UTC 时间自动转换成本地时间。
产品或技术总监应该考虑以下问题：
1. 这个特性解决或优化了什么问题（不作讨论，LeanCloud当然后自己的考虑）
2. 兼容性问题，以前的版本是不转的，现在要转了，必须要考虑以下问题：
(1) 是否优先考虑使用扩展的方式来提供这个特性（比如提供一个参数，让需要转的用户使用，这样可以不影响现有功能，一般软件设计不会轻易使用功能变更）
(2) iOS转了，Android, H5是否需要转，如果其它平台不转，会不会发生时间错乱，用户会confuse
(3) 如果Android, H5需要转，应该如何转才能保持整体的扩展性（每个工程师的思维方式是不一样的，应该达成一致的目标）
(4) 即便意识到3.1.2.3的问题了，3.1.2.4简单粗暴的回滚，是不是稍显随意？

再往上说一下，根据现象二，我目测，可能LeanCloud有一个大的产品方向管理，但似乎没有细化到一个集中式的需求管理，iOS、Android、H5是自己管理自己的需求，开发人员也是自己处理自己的模块。
这个自然是好的，充分给予开发人员灵活度，看的出来LeanCloud的工程师也都很厉害，但是作为一个跨平台的产品，如果没有一个集中大脑，带来的问题不是代码是否优雅的问题，而是产品一致性问题。

我个人觉得LeanCloud产品不错，只是从中看到一些问题，希望能与工程师们交流一下。

15-06-12

你好，

我是 LeanCloud CTO 丰俊文，非常感谢你能够如此直接和坦诚地指出问题，你的「拷问」涉及到团队、产品和工程，是一个很大、很严肃的问题，我白天还有一些琐碎的事情要处理，而晚上正好可以安静地思考和讨论，所以回复较晚，还望见谅。

这里我想稍微解释一下最近的这两件事情。

对于 6 月 6 日的服务故障，我们引入 Mesos 和 docker 容器技术，是为了更好地自动化运维，以保证平台更灵活的水平扩展能力。过去的这半年，我们业务增长比较快，有更多新用户进来，也有更多团队的业务成长起来，这对我们平台的弹性扩展提出了更高要求，所以我们尝试将服务容器化，让部署自动化。Mesos 系统上线之前我们进行了一个月的线下测试（尽管我们踩过了很多的坑，但是上线之后还是一样栽了跟头）。mongodb 的升级也有同样的原因，在升级之前我们也做过全量数据的测试。但是不幸的是 6 月 6 号还是出现了故障，具体情况我们博客有说明。我觉得这个事故暴露出来的最大问题，并不是新引入系统的兼容性或者新系统测试不足的问题，而是我们平台的隔离性不好造成的。我们做技术的都能理解，新系统接入或升级的时候，测试很重要，但再多的测试也不能保证就绝对不出问题，好的架构或预案会让系统宕机的时间尽可能短，会让影响范围尽可能小。在我们公开的 Trello Board 上大家也可以看到，我们现在正在优化的，就是我们平台架构，在不同服务之间、不同用户之间将隔离做到最好，这是治本的办法。

对于 iOS SDK 中时间的改动，它是 v3.1.2.3 版本中比较小的一个点，没有做太多确认就发布了，确实是我的疏忽，非常抱歉对部分用户带来了困扰！以后的确该如你所说的那样，做更全面的权衡。这一提醒醍醐灌顶，之后我们会指定一个 SDK 的负责人，他会跟进所有 SDK 的接口和功能变化，每一次发布都会更加严格地进行 review，避免类似的事情再次发生。

从你的追问和推测，能够看出来你工程和管理经验都非常丰富，确实让人佩服。我们目前的状况，和你的推测有一定程度的吻合。我们工程团队不大，基本上每一个工程师都需要独当一面。在管理上我们比较彻底地推行「工程师文化」，没有专职的 PM，我们认为每一个工程师就是 TA 本职工作领域的专家，所以我们会尊重每一位工程师的产品意见和 TA 拟定的开发计划。公司内部有一个 product committee 来管理产品的方向和迭代，而产品迭代计划则是在所有工程师集体讨论之后做出来的。在去年很长一段时间里，我们在产品和工程迭代上都稍显粗放，也出现过 SDK 端和服务端、不同平台 SDK 之间，接口和功能上稍有差异、release 节奏不一致，等等问题。我们也注意到了这一状况，所以从 2015 Q2 开始，我们开始放慢脚步，在代码质量的基础上更强调产品之间的一致性，强调文档的易读性，强调 demo 的时效性和权威性。在接下来的两个月里面，我们会在这些点上做出改进，并且会将我们部分模块代码直接开源，让开发者在使用我们服务的时候能够更明就里和放心。

LeanCloud 平台现在承载的用户数量一日千里，我们做出的每一处改动，确实应该如你所说，需要更全面的考量和测试，以保证服务的稳定和连续，这也是我们今后努力的方向。吃一堑长一智，我相信我们的产品和团队会吸取教训，不断进步，希望你可以继续监督和鞭策我们。

再次致以真挚的感谢，并祝商祺
LeanCloud CTO 丰俊文

1 人赞了这个帖子.
20-06-11
1

这个跨平台是怎么跨，感觉还是要多平台分开对接呢，我接了web平台，发布到安卓原生，在安卓原生上有些功能不支持@jfeng

20-06-17

你挖坟。。。