[TOC]
背景
阳春三月，春回大地，团队即将开启成立以来第一次全链路最深入的一个项目协作，也是我最期待的一个平台应有的能力之一，那就是全系统日志链路系统，有了它所有组件和模块的日志就可以串联起来，线上出现问题时就可追踪／可定位，极大提升解决问题的效率（时效）和降低运维的人力成本。
总体思路
纵观现在各大互联网的研发团队，基本都会使用日志Trace系统，有的是用的公司统一的日志平台，有的因业务特殊场景需要会定制化一套小型的日志串联追踪系统。而日志Trace系统架构总体来说大同小异，无非是“一条TraceId走遍天涯”的思路，如需更细粒度，再加一个模块间交互的Callid即可，如下图：
复盘开发过程
二月日志Trace插件完成基础全部开发
三月初hive组件接入日志系统开始埋点
三月中旬各组件模块开始介入日志系统开发（Kylin/WebService/前端/日志收集）
三月第三周第四周各组件集中开发，第四周周末有的组件加班加点
Kylin的开发过程大概如下：
3.12 - 3.20 Kylin接入Distributelog代码开发
3.21 - 3.23 代码自测、功能测试、全量测试，23号周五下班基本此次版本开发工作全部结束
（周一）3.26 部署demo北京／合肥环境，晚上与hive（带有日志新版）联调
（周二）3.27 demo联调hive发现影响任务提交计算，一直搞到晚上12点左右，最终确定新版hive配置Conf影响了Kylin集群的系统环境
（周三）早上8:30决定三件事：
- 武神：demo环境北京／合肥hive恢复至无distributelog的环境
- 欢欢：全力准备线上环境为明晚上线准备（hive／spark／es／logstash）
- 军：demo北京／合肥恢复至无hive-distribugelog的Kylin环境，合肥97/98/20三台机器上准备新的demo合肥环境
- 下午提交梅林测试
** 注意：**1. 砍掉<10%的hive-distributelog功能，风险>90%，即使原因已定位，此版本不上2. 3.28下午3点之前如还不能提交梅林测试的话，Kylin 29号版本决定不上线
（周三）3.28晚，梅林北京／合肥全部功能测试完成 + 通过
（周四）3.29 早上处理线上kylin事故
下午准备线上北京／合肥环境
下午上线北京集群新版 kylin-distributelog，观察一下午
晚上合肥集群上线新版本，21:30完成全部上线／回归计算任务+查询功能，确定无问题，v20180329 done
此次全链路版本暴露的问题
各组件接入日志全链路从上游到下游协调配合，较混乱条理不清
各组件自身接入日志系统后可靠性保障不够
日志系统Distributelog Tracelib 引入的新组件熟悉程度不够，Cover不住
提交测试时规则不明确，反复交互沟通确认，耗费时间成本
各环节时间节点预估不足
** 总结：归根到底，打铁还需自身硬啊！！**
发版后对这次版本的感悟
** 不抱怨（对自己），不责怪（对别人）**
Odeon是一个整体，十佳团队不会因为某个人特别牛而授予我们，也不会因为某个人比其他团队大牛相对弱些而不选择我们；
不抱怨自己，不责怪队友，遇到问题我们一起解决，在iflytek应该还没有我们团队一起解决不了的难题。要让自己所负责的事情让其他小伙伴可依赖
当我们告诉其他小伙伴自己的模块OK的时候，那么应该是意味着没有任何问题可以上线了，差一撇差一捺其实都还是不OK的状态
给版本各环节预留时间buffer，防止急忙上线出问题
方案 -> 开发 -> 自测 -> 联调 -> 提测 -> 冒烟 -> 正式发版