广信项目总结

广信项目的总结

背景

在5月20号入职后，经历了初期两到三天的业务了解后，就投入项目的第一次上线工作。其实这种情况下，各种问题我是考虑不到的。

问题

总结有三大类：

1. 刚入职业务不清

l 杭州集群，秒针集群的概念及网络拓扑不清；

l Flume,ftp分别处于数据处理的位置；

l Flume采集牵涉到的网络机器及拓扑，对应的业务方（地区，运营商，内容商），对应的日志文件格式，处理的中间结果数据存储及格式，最终落地hdfs还是数据库哪张表，项目的源码位置；

l ftp服务同上，网络拓扑及所处数据流的位置等;

l 甲方，乙方，第三方等概念模糊；

l C3,c2,探针，sdk，log.js，nginx等模糊

2. 平台环境问题

l 源码依赖添加scala依赖版本是2.11跟秒针确认对方给的错误答案，我直接依照当前版本开发导致后期任务出错；

l 成都测试，秒针线上集群环境各一套，而且环境配置及部署位置等不了解，服务的各种排错web界面没有方便的访问方式，线上资源受限；

l 网络环境问题:成都网络不稳定，局方机器权限申请，提交任务总是需要提到成都测试，需要步骤和网络影响很大；

l 脚本windown到linux跨平台问题

3. 工作沟通问题

l 工作中出现问题时，有时无法定位责任人，很多问题到头来推到大数据我这边，造成还不了解业务的情况下，问都不确定找谁；找到经常问的人，而我每次问都会对业务了解更多更清晰一些；

l 沟通中会因为指责别人问题，造成双方带有情绪；

l 有些问题是无法确定责任人，从不同角度认知不同；我认为工作中研发的角色太重，各种参与度太高；

4. 工作编排问题

l 广信项目虽说优先级最高，但是很多杭州线上问题经常出现，紧急度较高；占用过多时间排查原因和处理问题。

l 叮当小镇：很多问题不确定，在处理广信项目中，并发处理叮当小镇问题沟通花费时间很多，另外通话也不顺畅（手机信号，沟通条理性），初期的处理方式，内容界定划分有所理解不同，需要的磨合期。

l 跟测试之间初期沟通问题有些不对口（初次交流有些细节与以前公司不同双方处理方式不同磨合）；后期改善。

5. 代码问题

l 源码与项目对应关系，源码使用的最新版本分支不确认；

l 融合平台对应的报表与接口和数据表和大数据job的关系；

l Flume采集源码修改的内容造成的效果；

解决：

业务问题：找旗哥沟通整体流程，找测试，运维沟通各自负责的地区及业务环节。找小骆了解代码逻辑，找李伟协调项目进度。、

环境问题：与秒针沟通，他们给的答案是错的；跟小骆沟通；通过命令查看，确认，然后修正，重搭。

工作沟通问题：尽量沟通不携带感情色彩，可能表达会造成双方冲突，但是都会很好处理彼此情绪，不会造成敌对态度，很好处理工作和情绪。即使有冲突也会推进工作，规划彼此工作内容。

工作编排问题：跟各个项目经理沟通排期，并发处理各个工作，即使有些内容无法现在处理，也可以做到知晓，工作方向及每一步的内容，可以把握节奏。在处理完重急事情后，继续该工作。

代码问题：确定项目及分支，然后阅读代码，对比接口和数据库；对比报表，整理总结。

优化：

1. 杭州集群及所对接的甲方flume采集集群监控和报警平台搭建；知识库文档记录。

2. 大数据本地测试集群搭建，及版本测试升级改造。

3. 统一开发，测试，部署环境和数据库结构和内容。

4. 交流测试，运维大数据方面的内容及脚本。

5. 以后提供给甲方：大数据代码（产品），平台运维服务，杭州计算集群的计算资源服务，报表服务等内容尽量明确。否则一块内容可能牵涉整条大数据线的内容，造成工作大数据工作人员效率低下。当广度太大的话，分心太重，会造成排错的错误定位，另外因为分心会造成探查问题深度不够就会下定论。

在此感谢诸位同事的通力支持：特别是严总的任务优先级提醒，旗哥业务流程的梳理指点和项目中可能出现问题及应该了解的内容提点。