公司刚好经历了4年，随着企业和公司的成长，组织结构也演变了很多次，对应的企业内部的系统也分化出来N多系统来，经历了两个同结构类型的部门，复盘下过往历程以及一些思考。
1. 2015~2017 五洲会海购项目
1.1. Step1 - 销售端+ERP系统
- 销售端基于ECShop疯狂建站，定时任务抛单给ERP系统的订单模块
- ERP系统：涵盖了商品基础数据、订单数据、供应链仓储库存、财务几大模块
1.2. Step2 - ERP拆分阶段
- ERP单体应用，拆分成多个供应链子系统：
- OMS: 订单管理系统
- PDM: 商品管理系统
- WMS: 仓库管理系统
- FMS: 财务管理系统
- 销售端依旧没有什么太大的变化，新的项目依旧基于Copy-Modify-Run，依然是基于ECShop的维护
- 该阶段技术中心整体技术栈还是PHP，代码管理基于SVN，后端架构LNAMP架构，无文档管理系统
- 负责的五洲会初期
- 在ECShop上改写了框架部分，最小程度拉起了一个MVC框架，依旧重构了相关核心业务，模块重组&梳理，整体故障和维护成本下降
- 后端架构摒弃了Apache，直接都转到LNMP，基于phpfpm提供php脚本解析
1.3. Step3 - 技术标准统一&重构阶段
- 公司内部新项目试错很多，销售端的新项目的开发和维护成本很高
- 随着ERP的拆分，也分组出来各个供应链的业务技术团队，负责供应链的四块业务（OMS\PDM\WMS\FMS)
- 该阶段技术中心整体技术栈还是PHP，单体框架的引入和尝试（ZF、YII、Laravel…)，虽然故障较多，但整体的业务响应速度还是较快
- 负责五洲会前期，业务快速发展，五洲到家、B2B等业务
- 五洲会的除主要的销售站点，五洲会其他新的系统都统一选择了Laravel框架，有了框架和标准化的模块设计划分，维护成本较低，研发标准趋于统一
- 五洲会加入了文档管理与文件资源内部共享服务
1.4. Step4 - 新技术引入与内部技术尝试
- 很多销售团队业务同质化，技术部门引入Java团队、同时也设立了大数据、中间件团队
- 中间件搜索这块，之前都是基于Sphinx，全面转ES（之前有建议过转ES，上一家也是用的ES，最终还是转了)
- Java这块SOA团队，积极尝试新的业务（实际上是基于Java重构原有的商城业务系统）
- 负责五洲会中期
- 引入Swoole框架解决任务处理过程中，原有的cron的一些弊端
- 配合运维做一些CD的事情（DevOps)
- 五洲会后期
- 线下实体业没搞起来，海淘业务没有重大突破，最终搁浅
2. 2017年底~2019
转到电子研发，负责网站研发
2.1. 2017 - 业务维稳 + SOA尝试
- 电子团队
- 旧业务梳理、优化、调整，抗过双11
- SOA一边试错，一边在对接一些小站点业务尝试
- 技术中心
- 接入Wiki(基于Confluence)、Jira，都是基于Atlassian的产品线（java系，整体效果还是不错）
- 接入Gitlab，整体技术中心转Git
2.2. 2018 - SOA化
- 业务团队SOA团队进一步基础抽象，做了一些三端业务的通用服务，虽然后续对接过程中
- 电子站点团队转SOA重构，前面3端（PC\WAP\APP)，基于L框架对接完SOA（时间以及团队水平的衡量），分3次切完了线上流量（实际是4次，第一次出现了回滚，没有考虑到推广流量问题）
- 对接完后SOA，优化，扛过双11
- 技术中心
- AI、大数据、运维都开始有一定的改变，比如业务信息化、数字信息化（通过一些系统管理资源或业务）
- 服务意识有了一定的开化，一些小型业务尝试以独立服务形式提供（库存）
- 搜索、推荐、大数据曝光度度足够高
2.3. 2019 - 服务化、中台化
- 技术中心
- 服务化：扩大业务服务提供面，对原有业务进行服务分拆
- 中台化：期望做到资源整合与复用
- 项目制：期望通过项目制拉通各组织部门人员
- 个人
- 基于Golang+Istio+K8S的服务化解决方案探索（全面拥抱Golang、微服务)
3. 发展历程的一些收获与思考
3.1. 组织不断演变，出现过的问题？
- 新的技术和思想引入，这些都没有问题，但是忽略了最基本的人的问题；
- 技术过快的引入，但对技术没有吃透，组织中对技术的一知半解，缺乏架构设计思维以及业务和产品的思维，闭门造车、团队隔阂导致技术变成了业务快速发展带来了掣肘；
- 缺乏技术积累和沉淀，过新的业务无法吃透掌控，导致了目前的技术泥浆感，陷入技术债，业务跑不动，沟通部门墙；
- 组织结构变革依旧还是没有摆脱原有的弗雷德里克-泰勒的管理思想，树形结构以及层级管理思维依旧盛行
3.2. 管控一个新的业务 Or 接手一个老业务
- 第一阶段，优先业务发展和试错，打开市场，积累资源
- 业务小团队少，企业规模小的情况下，采用单体结构，通过模块化分，适当的系统分割，能够足矣支持业务即可，不要一味的追求技术的新奇，目前大多数的单体足矣支持很多企业的业务发展
- 小型技术团队难以支持起微服务套件，大多会停留在小规模尝试基础上，不要拿个锤子，总想着到处找钉子
- 这一阶段，注意用户数据的积累与规整，做好相应的数据收集规整，提前做数据治理，为后期大数据赋能准备（万一大了呢）
- 第二阶段，业务快速发展期，技术某些特定情况下，成为技术的瓶颈（比如大促、秒杀活动），遇到问题解决问题
- 尝试将单体应用中的某些模块，解耦独立出来，将高频业务与低频业务分割，重型事务性业务与轻型业务分割解耦
- 独立出来业务与原有的单体系统进行数据通信可以基于MQ解耦或者统一的API网关调用，同时也方便扩展
- 独立出来业务做成服务化，需要考服务设计的标准，为后续更多的服务迁移打好基础，因此，最前面的几个抽离服务要么做得比较好，成为典范，要么准备后面再继续重构
- 这一阶段，考虑技术对业务的支撑为主，同时提前预测好相关的技术转型储备（比如微服务架构）
- 由于服务的逐步拆分，导致整体业务应用的监控逐步变得困难，因此一个好的链路监控系统，需要开始设计（或者更早）
- 第三阶段，业务高速发展期，企业核心业务成型
- 考虑到业务很多基础形态已经足够清晰和明确，可以对应用系统进一步的重构演变，此时可以将更多的基础服务下沉，方便顶层前端应用的组装
- 微服务可以大规模的推广（依托于第二阶段的一些前期工作准备），此时，服务标准化、服务注册发现、服务治理、服务监控、CI/CD、容器化等都提出来了
- 微服务的开发需要有标准，方能自动化，以及快速CI/CD
- 业务和产品的抽象，以及业务与技术的结合，需要拥有优秀架构思维的架构师来打通。同时公司内部划分成多个职能组织，架构师是能看清楚全貌的人，需要拥有良好的沟通技巧，协调各组织成员，拉通项目研发流程（如果架构师在业务与技术方面没有问题，但在沟通方面存在一定问题，可以安排一个PMO或者项目管理配合）
- 各类新的技术的结合与数据反哺和加持业务，比如AI和大数据
- 第四阶段，分久必合合久必分
- 企业内部的服务，能做资源整合的做资源整合，比如中台化提升
- 大的业务，存在维护困难的，考虑逐步进一步拆分
3.3. 收获
- 人的重要性，企业成功，是管理者的成功，是员工的成功
- 业务、产品、技术，形成短板效应（研发吐槽产品文档不清晰，产品说业务没调研清楚，业务说技术不给力）
- 更进一步是招人考核，优秀的人能招来更加优秀的人
- 技术过早引入与技术变革，带来不一定是业务的增长，可能是掣肘
- 思考当下企业或团队存在哪些问题，是否新的技术引入就能够解决这些问题，使用技术的人能否hold住这块新的技术
- 提出有意义和价值问题的人，往往比解决问题的人更厉害
- 工具化、标准化以及自动化，甚至智能化
- 标准化，可以让做事情流程化（这个是工业机械时代的最大效率的提升）
- 工具化，可以替代原有手工或者人力做的事情（比如统计，报表）
- 自动化，在标准化和工具化的前提下，更进一步的释放人，以及提升工作效率
- 智能化，结合大数据，AI的一些分析，反哺和加持业务或者技术
- 基础理论的重要性
- 在解决各类系统底层或者性能优化时候，对计算机科学的理论知识了解得越透彻，则对软件的开发调优更加容易
- 软件工程师，需要有软件编写设计的能力（DSA、设计模式、编程语言）与工程实践的能力（SRE），除此以外，沟通和协助的能力也很重要
- 学习东西需要成体系
- 进一步看清自己的不足
- 圈子的重要性
- 跟对人的重要性
- 没有好的师傅，则自己找师傅，虽然比较难，有条件先提高自己的基线
- 学会提出问题，往往比直接给出解决方案有效（管理手段）
- 机会选择的重要性
- 技术演变
- 基于PHP的技术栈，到基于Golang技术栈的转变
- 直接到K8S+Istio，微服务技术栈
4. 下一步计划
- 理论强化，进一步完善DSA与CS；
- 强化工程实践，拿出一套微服务技术解决方案（基于K8S+Istio)，更多的项目学习、试错与总结；
- 增加见识，技术系统化，以及将技术整理和输出；
- 进一步深造，提升自己的基线（企业&学业）；
- 与业务更好的结合（技术服务于业务）；