2017最终回-终端运营质量分享会

在2017年的12月12日，终端项目组迎来了2017年最后一次全体质量分享会。（无疑是贴心的领导怕双十二剁手太猛熬不过元旦）会议召集近180人，作为2017年的总结，也是为2018年的序幕，会议有一如既往的改错前进，也新增了突飞猛进的积极借鉴。

开场：不忘初心，追求更高

每月都有质量分享，月月都有翻新花样。作为2017年压轴，本次会议隆重迎接新成员：红白小喇叭（记住它的样子，这将是本场会议出镜率最高的成员）

会议伊始，是一个原计划简短的开场，然而现实是开场者看着满座程序男触景而发，回想了自己怎样摆脱程序男 不善言辞标签的心路历程，一不小心就把场开长了。

感慨之余，开场者也不忘初心，在年末的最后一次质量分析会重申了每月召开质量分享会的目的：完成高可用的目标，在学习与实践中总结经验，成就更完善的生产系统。

质量改善的效果示例

作为本年度最后一次月版本质量分享会，会议也兼具了年度总结的性质。所以此次分享会新增了后台集中作业平台的年度质量改善内容分享。后台集中作业平台的程序员们分享了在这一年当中采取了多种方法对后台集中作业平台实行的质量改善措施以及改善成果。

后台集中作业平台结合2016年的故障分析，针对2016年度出现的程序问题、程序命名不规范、接口管控问题、数据库脚本问题、数据库接口问题、验证不完善、关联方分析不足、投产包总共8八大类的21个故障，确定了贯通开发过程的9大项目改造。

经过1年的质量改造，2017年度，程序命名不规范、接口管控问题、数据库脚本问题、数据库接口问题、验证不完善、投产包问题均未出现，整年度仅出现程序问题、关联方分析不足两类共3个故障。（具体措施及成果的详细信息请听小编下回或者下下回分解）

虽然会场表面一片寂静，其实不同应用的程序员们都默默解析其中可应用到自身的改善措施，拿起小本本快速记下。面对后台集中作业年度故障从21降到3个的成果，淡定表示钦佩。（内心os：还有这种操作！小编表示这种攻克故障flag的会议非常燃啊！）

故障分析 共商对策

同上次的质量分享会一样的是（如果有看小编的第一篇推文的话），本次分享会也对11月版本中的4个典型案例问题分别进行探讨。不一样的是，为了保证会议的新鲜度，主办人冥思苦想了一个新形式，提前将故障分析内容分发给小伙伴们，然后--你的故障他来讲。

此次会议分别从错误提示信息专项、需求分析不充分、程序问题、批次问题四个方面入手，挑选4个案例分别进行剖析，并且提出相关的整改方案。

会议中就会看到不断有程序员像打地鼠一样被点兵点将，对分享会中的案例措施发表自己的疑问和看法，相互切磋。当然高手过招，旁观者总是眼花缭乱的，总而言之大家都在故障的分析中总结了新的经验，学习到了新的方法。（掩盖小编IQ跟不上高手们的事实）

虽然当晚长夜漫漫，但是多动症小编还是努力保持了2.5小时的高度集中，实现会议的召开不是为了批评而是为了改善的目标，将大家针对4个案例的问题类型提出的整改措施归纳如下以供回顾：

1.质量改善的必要性

短短几年间，随着广发业务的扩散，功能的增加，应用大量增加的同时也意味着风险加大，因此核心与渠道开发处向高可用方向转型成为必然趋势。

2.加强业务沟通

作为应用负责方，与业务部门或熟悉业务的人加强沟通，可以有效判断需求的合理性，减少故障发生。

3.了解代码原有场景

改代码难于写代码，是否了解原有场景和既有规则，可能意味着改代码的时候是否会破坏原有代码。

4.前期工作的重要性

需求分析作为开发的重要环节，应更全面的考虑可能出现的情况，避免因认识的局限性，导致后续开发应用出现失误。

5.数据迁移的环境检查工作

拿到既有规则/逻辑，也应深入了解判断。做数据迁移时也应做好基础工作，提前检查双方环境是否满足迁移需求。（程序小哥原话梗概：不能天真的认为既有即可用）

直击灵魂深处的审问

2017年结束在即，年初的目标实现了吗？

（首答：没有）