一、日常问题

1）涉及多端的BUG

　　我们组维护着一个基于 socket.io 的即时通信的常规页面，前后端都由我们处理。这两天一直报错说匹配不到聊天对象和使用时很卡顿。

　　匹配不到聊天对象这个问题好排查，账号没锁住导致的。使用卡顿，排查起来就比较麻烦了。

　　卡顿分为两种，第一种是进入页面时卡住，页面加载进度条滚到一定位置后就进行不下去了；第二种是在页面中打字打不出，键盘也弹不出。

　　这两个问题会涉及到客户端、运维和我们组，由于是周末，推进困难，有人看到消息也不回，发语音会议也没人参加。

　　种种碰壁后，就会带点情绪，自己在情绪管理这块还是很欠火候。后面就找各个组的 leader，由他们来排查。

　　技术沟通后，再把测试也拉进排查问题的群里，让他们在验证问题是必现还是偶现，是否能根据某些条件重现。

　　第一个问题，进度条卡住，有可能是网络服务问题，也有可能是客户端问题。网络服务找运维，根据账号的 IP 反查是否访问了那条地址。

　　发现是会出现 499 以上的错误，于是运维先加资源，上班后再做优化。

　　第二个问题，让客户端去单独排查了，如果他们需要一些位置的页面埋点，我们会第一时间配合。

2）推诿

　　这个问题发生在其他组，对我们自己组也是个警醒。

　　运营人员在3月提了个高等级的BUG，后面在4月将等级进一步提升到了急。但是直到6月份才解决。

　　并且解决起来其实很快，但是却拖了几个月，运营人员非常质疑技术部的态度问题。

　　为此特地开了个总结会，虽然在总结会上，将问题归结于流程不完善。但是大家心里其实清楚，主要还是两端的人在推诿，谁也不想管。

　　当时的客观原因是在家办公，沟通不畅，业务多，正在赶进度，还有BUG系统正在迁移，开发人员没注意到，总之种种因素合在一起，就将此BUG给淹没了。

　　其实在去年的时候，开过一次会议，就是要大家能积极反馈BUG修改进度，但是随着时间的流逝，又转回来了，又需要一遍遍的提醒。

　　那么在这次复盘会议之后，要求BUG先提交到测试，测试分配给开发人员，然后开发人员来推进BUG，若需要其他组的人协作，则由正在修复的开发人员沟通。

　　我个人觉得，这个问题的本质是生产力跟不上业务变化。开发人员会觉得业务都搞不完，哪有时间管这些涉及多端且比较麻烦的BUG。

　　要想破局，需要加人，目前也正在做。还有就是对线上问题多上点心，体谅业务人员，尽量多帮她们提升幸福指数。

3）主动性

　　公司最近有个版本需求，优化会员商品，在客户端和公众号中都有购买会员的页面。

　　服务端此次会在原表中修改会员商品，他们的改法比较粗暴，直接将代码推到预发，然后下架旧商品，客户端中有段时间就会无法购买。

　　虽然我们的公众号中已经对新旧商品做了鉴别，但是他们将所有商品下架后，连带公众号中的购买页面也不能使用了。

　　其实这完全可以避免的，和自己组员沟通后了解到，服务端的这个操作并没有通知到我们。

　　但是我们得主动的强调你们其他组的改动不能破坏我们维护的线上业务，因为出事故了，找的是我们而不是别人。

　　所以我们有责任保持业务的稳定，下次还是希望组员主动的预判出项目的风险点，以及清晰的表达出我们的诉求，不能做背锅侠。

二、工作优化

1）对外的SDK

　　最近运营想做一个活动，但是产品和设计都没资源了，于是她们自己找了外包来做。

　　一开始我并不知道我们组也要参与进来，后面运营希望能过将活动传播，那么就需要配置分享。

　　然后她们还想做埋点分析，这些数据希望存在自己的服务器中。

　　最后还要部署到我们的服务器中，这样也方便发送埋点。

　　前面两个功能，需要我们组提供SDK，其实之前根本就没有想过，我们也会对外。

　　这次有对外的机会，那正好也可以练练沟通和SDK的封装。

　　在改造的过程中，也发现了些问题，例如分享配置失败、埋点功能过多等。

　　在做了优化和瘦身后，写好在线的说明文档，再发给外包人员，在线的话可以实时更新，比离线文档方便很多。

2）不要我以为

　　最近有个客服入口优化的需求，我理解下来这个需求的流程很清晰，但在让我的组员实际操作中并不是如此。

　　整个流程就是先让微信静默授权，得到 openid，然后去查询用户是否已绑定，若绑定了跳转到客服咨询页；若没有则跳转到登录页面。

　　在登录页面点击确定后，将 openid 和 userId 绑定，下次再进来就不需要手动输入了。

　　自己组员开发时将查询绑定的时机移到了登录按钮中，点击确定的时候，才去判断是否已经绑定，这明显与之前的流程不符。

　　究其原因，很大一部分是因为没有文档，其实如果有一张流程图的话，大家就能一目了然的知道什么阶段做什么操作了。

　　但之前都是口述，甚至都没画草稿图，大家心里都没概念，虽然一顿输出，但是理解不了多少。

　　这就导致开发周期变得很长，我自己也很诧异，发生了什么事情。未来在阐述逻辑时，还是得图文并茂更容易让人理解。

3）量化工作指标

　　公司要求我们组量化工作指标，其实就是为了更直观的看到我们组的工作情况。

　　每个双月会手动计算需求完成率，以及协作满意度问卷。

　　除了需求指标外，还建立了许多项目质量的指标，例如接口超过2秒算慢响应、500错误数、白屏时间分步等。

　　围绕质量指标，我们组展开了很多优化的工作。

　　首先是数据库的优化，包括 MySQL 和 MongoDB，就是建立合适的索引。

　　其次是代码逻辑的优化，例如减少查表的次数、增加数据中间层、修复代码 500 的错误等。

　　还有就是网络层面的优化，例如引入 CDN 加速、开启 HTTP2.0 协议等。

　　以慢响应比率为例，从最初的0.23% 降低到了 0.05% 以内。

　　指标量化后，让我们的工作可以更加明确和清晰，也更有目的性。