我其实就是想水一篇，反正也没人看。公司给来我一个参加技术大佬们周例会的机会，做了一些笔记分享一下

9PM项目周会笔记19/7/22

第一部分:故障分析

对Q2的故障数据进行分析和总结，数据来源CMDB，分成三个部分进行分析

篮球

• 基于数据的故障比较多，数据是个比较大的问题

• 基础设施部分也有故障

• 足球的故障和篮球类似，数据出问题的概率比较大

社区

• 大部分故障是大流量造成

• 大流量问题相对 安全、误操作等问题更好解决

基础(搜索、推荐、基础设施)

大流量占比还是比较大，运维在定时任务、DBA在建立索引等部分容易发生故障

处理时长

大流量问题容易处理（30分钟内），安全和上云问题较难处理（12小时以上）

总结

故障分析总结

• 篮球的故障主要是数据导致
• 社区的故障主要是大流量导致
• 基础运维的故障主要是操作导致
• 社区和基础都涉及到安全问题
• 故障问题和流量大小成正比

下周的会议会分享改进措施

个人总结

因为我目前在足球组工作，足球组GDC面临的问题和篮球组类似，所以对篮球组数据故障高发很有感受，逻辑bug很少，大部分需要处理的bug都是在为数据源问题打补丁

从我遇到过的问题和工作中的实际情况来看，足球组数据故障的原因有

• 数据源种类太多（多个第三方接入、爬虫、游戏数据导入），缺乏一种灵活切换数据源数据的策略
• 数据源不稳定，很多比赛数据由第三方提供，有时推送过来的数据有误，需要建立数据校验机制
• 测试困难，因为比赛数据是实时提供的，而我们没有赛事回放功能，导致测试的工作推进缓慢
• 运营操作失误，没有对运营的操作进行后台约束

目前篮球和足球大部分的比赛都处于一个休赛期，大流量导致的故障并不多，但从社区的故障分析来看，如何应对大流量也是有必要重点考虑的。在足球GDC的重构计划中，这些故障分析很有指导意义，算是前车之鉴吧，新版的GDC架构也针对这些问题做了相应的处理。

第二部分:立项申请-文档平台2.0

申请人在目标、策略和计划、资源需求这三个方面未与大家达成共识，项目需要再议

申请人的目标

目前文档平台1.0运作过程中产生了缺乏标准、互动少、文档查找困难等缺陷

申请人的目标是先做活一个板块,增加互动，衡量质量, 最终能够提升整体研发的氛围,做好技术沉淀

申请人的策略和计划

成立文案评委

创立一个虚拟组织极客团，理想状态的极客团成员由公司内热爱技术，乐于奉献的人员组成

每个人在“分享殿堂”内的基本职能是对一篇文章进行评论。

策略

2.0的思路是先在一个区做尝试，做出一个“爆款”，再推广到其它区

所需资源

9PM小组提供帮助，每位leader提供1-2人担任“极客团”初始成员

讨论热点

大家问的问题都很好，但这些问题不应该是立项会议的重点，因为提问的人太多了，拖长了会议时间，应该言简意赅的表达同意立项或不同意立项的观点和原因

• 为什么要强调无偿奉献？是否最终变成强迫？(希望希望保障评价的质量等？)
• 如何保障对每个成员的成长？(作为绩效考核的参照等？)
• 文档平台内的文档类型有哪些？(设计、故障记录、经验总结等？)
• 如何保障评判文章的质量？
• 文档平台目前最需要服务好产生内容的人，如何才能提高文档质量?

个人总结

大家如果能从一开始按照立项评判的标准，围绕立项评判标准发表自己的想法，可以提高立项会议效率和质量

立项评判的标准：

目标、策略和计划、资源

个人对创建“极客团”这个想法很支持，但是大部分人在质疑“极客团”成员为什么会无私奉献，对于一个成员流动的“极客团”来说保证每个人都能“用爱发电”确实很难，所以需要考虑用什么形式运作才能保证“极客团”的成员是有成长的，对整个研发团队是有帮助的。很希望虎扑能营造出良好的研发氛围，有机会的话希望自己也可以参与其中

给我的启发是

• 不管是作为申请人还是评审，都要围绕目标、策略、资源这样的标准阐述自己的观点，规范才能高效
• 理想很美好，想将理想落地实施需要面对很多挑战和质疑，理想还是要有的

第三部分 java化进程

这一部分主要介绍了各组的开发进度

个人总结

如果你的进度延期了，需要说明延期的原因并确定新的完成时间。因为你的开发任务可能就是别人任务开始的前置条件，延期很可能会影响到其他组的开发工作，所以要尽量避免延期，如果不得已延期，也需要做好沟通工作，重视自己手头的每一个开发任务

第四部分 CI&CD项目

与持续集成相关，公司内的各类项目都在有计划的接入

第五部分 招聘流程化系统

对项目进度进行了跟进

第六部分 架构评审

架构评审的作用是对提交的架构文档提出优化和建议点，本周一共有4场架构评审，其中足球组架构评审二评通过

个人总结

我参与了足球组的这两场架构评审，谈一下感受吧

第一次未通过的原因是因为文档不全，思路不清晰。第二次文档补全后通过

我参与的部分是画ER图。在设计时我严格按照三大范式绘制各各表之间的关系，因为业务需要，所以多张表之间相互关联，关系十分复杂，评审时被建议增加数据冗余来提升查询效率。我们原本打算通过缓存来解决查询效率的问题，但架构师们的想法和我们不一致，至于到底哪种方法最适合，我们还需要再调研。架构评审的效果很明显，对组内的每个成员都是一次提升训练。

因为排期比较仓促，而且又是一个重构项目，所以大家对文档编写的重视程度不高，导致文档质量不高，许多细节也没时间仔细考虑，这些问题是需要改进的地方，以后需要重视文档的编写工作。

整体感受：

• 架构文档需要提供各种个样的图，ER图，物理部署图，用例图等，需要练好基本功，这点很重要
• 架构涉及的不仅仅是开发工作，需要和运维和DBA沟通，提前做好流量需求评估
• 尽管自己的架构能力不足，也不要有心里负担，重要的是讲清自己的逻辑，架构评审时会有架构师协助你改进
• 架构文档的目的不仅是用来参加评审，也是为以后加入此项目的新人提供第一手资料
• 需要训练好自己的口头表达能力，说清自己的想法

补充：会议总结

老殷希望各位对ppt的要求再高一些，字体能够统一

故障管理

• 目标用户：虎扑网友
• 给用户提供价值：可用性的服务体验
• 给服务的提供者的价值 为产品、运营、技术提供指导和规范

故障生命周期内管理

原则：谁 为 什么结果 负责 怎么办

分别对故障前，故障中，故障后进行处理

什么是故障

影响用户可用性，对于虎扑来说数据很重 影响用户使用服务的可持续性

• 涉及到钱
• 影响服务可用性
• 领域内特殊的服务（比如篮球的数据）

目前还没有过被NOC半夜打电话处理故障的经历，所以这部分目前没太多感受

但在虎扑一个月的工作经历已经能感受出技术组对故障管理的重视程度