在JD第一次参加了大促的备战工作，我所负责的系统也要应对618当天的流量洪峰。

这半年开发的三个实时相关的工具都上线了，binlog采集、准实时hive表数据、日志分发。

在618备战期间，我对这半年的开发有很多的思考，主要是平台运营、工具特性，性能与监控等方面。

平台型和工具型

作为一个工具，你可以只关心功能，关心配置的灵活度，水平扩展能力和性能的极限。

但是作为一个平台型的东西，这些是远远不够的。

比如平台上的任务一定是绝大多数任务压力很小，有少数任务流量压力很大。

业务上也会出现，某些任务只在一些特定的时间流量压力大，而其他时间流量很低。

数据的表现上有条数多，或者单条体积大。甚至还要考虑有一些任务所使用的网络比其他任务要差一些。

单从工具的角度来说，我们的三个tool的表现都非常优异，每种任务都可以使用3-4个性能档位配置，

工具的配置非常灵活，暴露的可调节的参数也非常多，核心逻辑采用状态机等设计模式，

非常好的兼容能力。性能上也做了诸多优化，binlog采集的性能甚至超过了正常从库同步的性能。

临时解决问题

在任务上线的初期，经历了两周的阵痛，每天都有很多细碎的问题，比如某些任务延迟了，

某些任务长时间无流量，某些任务经常报错等等。经过两周对监控的调整，大大降低了告警的次数，

并且摸索出一套简单的运营办法，可以解决绝大多数问题。但是偶尔还是会有特例，

在备战618的过程中，还是需要花非常多的时间去梳理核心任务和数据量大的任务，提前进行扩容。

甚至在618前的一两个小时里，我们还在梳理增长迅猛的任务，并适当的扩容。

这种工作无论你花多少时间，多么有耐心，还是会有遗漏的情况，因为这些都是实时数据或者

准实时数据，临时人工处理一定已经晚了。

基础准备

因为现实业务上的复杂性，所以我们的任务本身需要做一些基础的准备。

第一、做好水平扩展能力，可以通过增加一个docker副本来实现性能的水平扩展。

第二、当不能通过水平扩展提升能力时，可以通过增加资源来提供能力，比如cpu、mem。

其实很多业务系统经常是增加了资源并不能提升处理能力，或者说不满足预期。

第三、Job本身能够估算出自己的余量，这一点非常重要，能做到这一点的少之又少。

第四、能够借助像docker、k8s等方式对运行时环境进行管理。

未来

在产品端开发和运行时任务之间应该有一个运营质量管理系统，将监控和伸缩容量等结合起来，

通过规则集或者AI相关技术，来解决需要大量人力时间的工作。

在docker盛行的年代，传统运维方式发生了变化，监控也随之发生了变化，

同样运营方法也在产生着巨大的变化，接来下几个月我会投入Flink相关的开发工作中，

建设一个实时计算的平台，运营的实时化问题，会被我当成一个业务场景来对待，

希望今年年底前能够彻底拜托人工运营的现状。