所有的问题最终都是人的问题。

选人

• 使命 愿景 价值观
• 思维方式
• 高效 沟通 STAR
• 知识面 基本功 深度 广度 学习精神

用人

• 动作 任务 心力 愿力
• 绩效管理 OKR， 公正 没有绝对的公平，定期沟通，及时指出不足
• 目标管理 超出预期

留人

• 团队文化 分享 协作
• 增值 学习 上升空间 时势造英雄，给与足够的挑战
• 利益 短期利益与长期利益 期权
• 超出预期

人的成长的过程其实就是填坑的过程，技术如此，管理如此，生活也如此。十多年来作为团队首席填坑官，在此分享些技术方面的填坑经验。

指导思想 - 相信科学

• 有时候会有些不好重现或者比较意外的问题出现，请减少无意义的解释说明，相信科学，抓紧时间收集信息、分析问题，这种情况往往是真的有问题，而且有时候是一些非常低级的错误。对于填坑人员来说，需要牢记墨菲定律：
  1. 任何事都没有表面看起来那么简单；
  2. 所有的事都会比你预计的时间长；
  3. 会出错的事总会出错；
  4. 如果你担心某种情况发生，那么它就更有可能发生。

发现问题

• 问题一般来源于监控报警、客服反馈等，为减少损失和尽量在用户反馈之前发现问题，除传统的系统环境监控报警外，通过日志分析进行业务监控报警是很有必要的。

定位问题

• 常用方法有排除法、分治法、对称法、替代法等，逐步缩小范围，对系统各模块的边界及关键节点要事先了解。
• 日志是定位常规问题比较快的方法，因此需要有日志规范，以Java为例：要求使用自定义异常；对于关键路径或节点需要记录日志，通过记录TraceID、SpanID能做到全链路跟踪；如果是分布式系统，需要搭建类似ELK这样的集中分析平台。
• 网络问题抓包分析会比较快，特别是涉及第三方调用时。

• 性能问题是比较复杂的，一般需要对调用链上各节点逐个排查来找到性能瓶颈。

• 在混乱中找到线索犹如在大海中发现灯塔一样令人开心。

解决问题

• 问题定位到以后就是解决了，这时候需要全盘考虑优先级和影响范围，不能改出新问题来，解决问题怕的是代码盘根错节，很容易拔出萝卜带出泥，此时模块化(不一定要微服务)的优势就显现出来了。
• 功能模块设计时可以加上一些开关，一旦有问题可以及时止损。
• 尽量考虑扩展而不是替换，修复后跑一遍单元测试和自动化测试。

事后复盘

• 团队需要规范化的管理，事后需要组织团队对问题进行复盘并记录到知识库，避免类似问题再次出现。

未雨绸缪

• 预防问题出现其实比解决问题更重要，但问题少了碰到有些老板会觉得技术人员没事干，这就尴尬了。
• 规则越严谨，效率可能更高。
• 对团队的要求-职业度
  1. 态度 遵守设计和操作规范，少挖坑
  2. 责任心 挖坑要填坑
  3. 团队精神 队友挖的坑也要帮忙填
• 对团队的要求-专业度
  1. 保持学习精神 团队内外定期分享
  2. 提高PRD质量 能把产品描述清楚，为什么用户解决什么问题，所有可能的场景
  3. 提升代码质量及设计文档(类图、时序图)质量 遵守设计原则和规范，高内聚低耦合，提高单元测试覆盖度，持续重构优化代码(可参考SonarQube反馈)
  4. 提升工作效率 自动化测试、自动化运维

好处

• 减少人力投入，短期成本相对低
• 人力不足的情况下有助于商业目标的快速实现
• 外包公司一般会有半成品，如果公司业务不成熟，会有所帮助

存在的问题

• 项目管理水平要求较高，特别是需求管理、进度控制、成本控制
• 大部分外包公司使用技术较为陈旧，代码质量较差
• 项目上线后响应较慢，无法快速落地公司的商业思路变化

• 按照业务逻辑拆分，拆的粒度与组织结构相关，人少的情况下不建议拆的太细，三个火枪手维护一个服务
• 按照可扩展性拆分，经常变动与很少变动的分离
• 按照可用性拆分，避免非核心业务影响核心业务
• 按性能拆分，将性能压力较大的独立出来
• 系统架构与组织架构最终将接近一致，业务线、中台(订单、会员、支付、风控、商品、库存、物流)、财务(账户/结算)、基础架构……

2016年底得到一次重新组建团队的机会，距离上一次技术架构搭建也过去2年半，因此开始了新一轮技术架构搭建之路。

团队

• 20人
• 开发 产品 运维 测试 UED 风控 运营
• Android/IOS 官网及后台BOSS系统 风控系统 大数据 第三方接口管理

产品业务类型

• 白条
• 消费分期

原分布式SOA架构存在的问题

• 业务模块边界不够清晰，粒度较粗
• 缺少自动化的服务注册和发现
• 缺少集中的配置管理及下发
• 部署脚本要处理的内容多，易出错
• 缺乏对熔断和降级的自动处理

新技术栈的选型及踩过的坑

• dubbo/dubbox 阿里本身已较少使用，缺少更新和后续支持(2017.8开始有阿里团队维护)

• spring cloud netflix成功应用，pivotal提供支持，技术栈全面，最终选择

• spring cloud eureka feign sleuth config hystrix swagger, mybatis druid
• aliyun slb https oss rds redis, rabbitmq ecs自建
• jenkins maven sonarqube mock jmeter

• filebeat logstash elasticsearch kibana

• eureka非实时下线错误节点
• 熔断时间的设置
• jvm参数配置

后续待研究

• 加强单元测试
• 容器化
• es日志数据分析
• 性能压测
• 增长黑客
• etl、数据仓库、数据挖掘

从2014年6月开始职业生涯发生变化，来到一家互联网金融公司，开始了组建团队、搭建技术架构之路，在此对这一年多的经历做些总结。

团队

• 20人->75人
• 开发 产品 运维 测试 UED
• 官网及后台BOSS系统 大数据 风控 移动端 APP WEBAPP(H5)

架构&技术演变

• 快速迭代机制 建立版本、分支管理方法，每周迭代
• 使用MAVEN作为代码项目管理，搭建MAVEN私服
• 项目独立 分为前台、后台、业务处理中心、交易中心、批处理
• 分布式架构 每个项目部署在多个虚拟机，高可用，多活，负载均衡
• 分布式锁 使用zookeeper实现
• 分布式session 曾考虑使用zookeeper作为存储容器，发现性能不佳且不方便查询和清理，改为redis
• 分布式缓存 使用redis作为缓存实现，使用spring-cache管理缓存
• 分布式日志 使用mongodb集中收集日志，后因查看不便，改为elk
• 分布式监控 使用zabbix监控服务器状态 通过邮件和微信企业号推送监控信息
• 分布式事务 使用异步消息队列处理分布式事务，redis作为轻量级消息队列实现
• 数据库设计 交易有迹可循
• Web安全 HTTPS，XSS Filter，双向验签，限制失败尝试次数，限制调用次数，nginx端使用lua实现过滤规则，实时监控TOP 20请求，DDOS防火墙，Druid sql防火墙，前台敏感数据隐藏
• 防重复提交 前台使用Token机制防重复提交，后台使用乐观锁防重复提交
• 性能优化 动静分离、开启gzip、优化业务减少请求、使用异步消息减小事务
• 动静分离 将静态资源从前后台分离，并对项目透明，项目目录mount到nfs
• 代码质量 搭建代码审核平台reviewboard，强制代码审核；自动化测试；单元测试 spring-test
• 封装3个基础框架包 utils,dbutils,appframe
• 自动化打包 使用脚本自动化打包及部署，并执行测试用例，使用saltstack下发配置文件

后续待做

• 培养优秀程序员 招聘前端工程师
• 规范项目管理平台redmine的使用
• 需求规范
• 设计规范 设计文档
• 加强单元测试
• 每日构建及自动化测试
• dubbo SOA治理，负载均衡，提高通讯性能
• 分布式日志收集处理
• 监控平台 运维、业务、日志
• 账务系统银行托管

先发优势

技术门槛

独特的用户体验

books

• 活法
• 我给你讲个笑话 你不可以哭
• 40岁，另谋高就
• 给你一个亿，你能做什么
• 给你一个团队，你能怎么管
• 创业可以走直线
• 通向财务自由之路