前言
时间先回退到2011年，那时候我刚加入猪八戒，加入公司之前我还不知道svn、git是什么东西，连发布代码也是用的最传统的FTP上传方式。而早在2009年，来自Flickr员工在一场会议中所揭露了如何改善Dev和Ops的合作，达到了单日10次发布的高速度，催生了后来的DevOps运动。（题外话FTP的方式几秒就能发一次代码）所以DevOps到底解决了什么问题呢？接下来结合猪八戒的不同阶段给大家介绍一下我们的DevOps演进之路。
猪八戒devops演进之路
1、初创期
虽然2009年就提出了DevOps，但国内很少人听说过这个名称，但是这并不代表我们没有去解决dev和ops的协作问题。
那一年猪八戒网仅有4台物理机，托管在某IDC机房，总的工程数20左右，均为PHP工程，技术人员20左右，由于迭代的频率很高，每天发布30+次，公司仅有2个运维人员，所以如果没有自动化的方式是很难完成这么高频率的发布的，所以有了公司第一版的“DevOps”。
如下图：
上图的流程特别简单，使用svn管理代码，有两个固定的分支，一个用于发布到测试环境，一个用于发布到线上环境。研发提交代码后，通过svn自带的hooks功能配合rsync将代码分发到对应的服务器，由于当时所有应用都是部署在一台物理机，所以只需要全量pull即可完成发布。通过这套简单的流程即可实现研发合并并提交代码即可发布上线。解决了快速发布的问题。
2、业务增长期
时间到了2013年，业务也快速增长服务器、应用、研发人员都出现了很大规模的增长，伴随着很多问题也出现了，随意的发布让线上环境变得很不稳定，配置文件变更不当导致全站500频频出现。虚拟机的引入也让之前的发布方式变得难以支持。所以此时急需对之前的发布方式进行升级，来满足现阶段的需求。
如下图：
这个阶段最大的变化是大量使用虚拟化，并对应用进行了独立部署，同时为了控制发布取消了svn hooks引入了SYN系统（我们内部取名）。
SYN主要解决以下几个问题
1、权限控制（可以控制到工程、环境、发布时间）
2、引入exclude_list来解决配置文件变更的问题
3、工程代码映射关系（CMDB1.0维护工程和机器的关系）
4、代码分发
通过SYN系统的引入，线上的稳定性开始变好，配置文件研发提交申请由运维人员统一进行维护，出现配置异常的情况也大幅下降，然而发布的效率也相对之前减少了很多。
3、多语言
时间到了2015年，业务规模和人员规模再次出现了大幅增长，开发语言也由以前的纯PHP到大量引入JAVA语言，显然之前的SYN系统已经不能满足需求。这时我们开始引入Jenkins来解决CI的事情。其他结构基本没有多大的变化。
如下图：
我们继续沿用了之前的SYN系统来控制权限，但是CI部分全部交给了Jenkins，这个阶段我们的CMDB也完成了代码、工程、资源的100%关联。所以CD部分也变得非常方便，有一个短暂的阶段为了解决多部门联调的问题，出现了10套测试环境，得益于CMDB信息完善以及一些自动化的能力，所以在资源足够的情况下可以很快速的完成一套环境的搭建。
4、微服务、容器
时间到了2016年，这个时候公司也引入了很多大厂的大牛，微服务、容器、DevOps也进入了我们世界，于是就有了长达2年的DevOps研发之路。
先看一个图：
这种架构我相信了解过DevOps的都不会陌生，这里我重点介绍3个不一样的地方。
（1）基于JIRA的研发流程管控。通过JIRA管理研发流程，发布的时候严格校验状态，确保所有发布均符合研发规范。
（2）SDL和流水线结合（DevSecOps），从创建工程的安全评审，到每次提交代码的自动扫描，再到发布的安全测试，确保每一次发布的代码都是安全的。
（3）猪八戒容器云，完美实现了流水线和多个K8S集群的封装，解决了跨机房部署等问题，目前猪八戒网90%的工程均运行在容器中，较之前使用虚拟机部署减少资源60%以上，大幅减少了IT成本，同时服务发现、滚动发布、动态扩容等也让业务更加稳定。
附容器云项目核心组件（如果大家对容器云感兴趣可以在评论区留言）：
目前我们的流水线每天支持业务发布150+次，发布成功率99.8%+，完成一次从测试环境到线上发布平均耗时595s。
5、一站式研发平台
DevOps只是研发过程中的一部分，所以我们需要有一套新的平台来解决工程的全生命周期管理。去年10月份我们开始以需求为出发点，围绕工程全生命周期管理的平台打造。底层架构和上面的没有什么区别，只是对产品做了大量减法，让产品的用户体验更好，下面从功能角度简单介绍一下我们的一站式研发平台。
（1）重新定义工程类型，对历史所有工程进行盘点最终梳理出6大类型便于研发准确的创建工程。根据类型不同最小化的让用户输入信息。
（2）本着谁定义，谁负责的DevOps理念，一站式研发平台把所有权限交给了工程负责人。工程负责人可以完成配置、发布，接收告警等所有工程管理配置功能。
（3）需求发布
前面已经提到，我们对研发流程管控是较为严格的，任何需求的发布都需要经过严格的流程审批，每个流程可以发布的内容也是严格限制的。为此我们引入需求管理，把每次交付串联起来。
（4）技术架构
一站式研发平台围绕项目全生命周期，以场景化的方式把可能用到的研发工具串联起来，各个功能仍然由不同的子系统完成。整体架构如下图。
对于云原生的一些看法
我个人是比较拥抱云的，特别是云原生，我们目前业务虽然都在云上，但是全都是使用的云的基础设施，其他服务全都是内部团队在做，从投入的角度来说确实很大，而且期间也不乏走了很多弯路，我也听到很多关于拥抱云原生应用后的一些担忧，确实有利有弊，自建对于技术团队来说更加灵活因为技术相对可控，一旦拥抱云就会有很多限制，毕竟云上都是通用能力，如果有大量定制化的需求很难得到满足。另外如果企业已经投入了大量的成本有一套自有的能力，上云短期也会有很大的适应、改造和资金成本。
引用孙子兵法开篇的第一句话“兵者，国之大事，死生之地，存亡之道，不可不察也”。是否拥抱亦是如此。
