作者的技术团队负责了数十个项目的开发和维护。我们疲于各种系统之间，解决着各种琐碎的问题，如何从这些琐碎的事情中解脱出来？devops成为了我们唯一的选择。文章是结合当前环境和团队规模对devops实践的总结。该解决方案简单易懂，易于实施且有效。实现方式先看流程图：工程师在本地开发，开发完成后提交代码到代码仓库，【自动】触发jenkins进行持续集成部署，部署完成后收到结果邮件。项目运行过程中，可以通过日志系统查看程序日志，任何异常都会触发监控系统报警。工程师可以在上线后完成从编码到反馈的过程，形成一个完整的闭环。运维负责提供完整的流程工具链，协助处理异常情况。工作量减少，但效率高。自动触发jenkins部署是通过svn和githooks实现的。是否自动触发由项目内部沟通决定。我们目前没有自动触发。原因是QA不想在测试过程中被自动触发的部署打断，但是也可以方便的在jenkins上手动触发jenkins的执行，从svn拉取代码-->编译-->JS/CSS合并andcompress-->其他初始化操作-->生成最终的线上代码包，通过Dockerfile打包成镜像上传到dockerhub，然后触发kubernetes滚动更新镜像，里面包含基础镜像+项目代码。基础镜像是根据项目运行环境打包的最小运行环境（不含项目代码）。根据项目依赖的不同技术栈，我们封装了很多不合理类型的基础镜像，比如包含nginx服务的基础镜像，包含jdk+tomcat的基础镜像如果发现程序上线错误或者有短时间内无法解决的bug，可以通过jenkins快速回滚到之前的镜像版本，非常方便。流量骤增，可通过kubernetes快速调整容器副本数软件及工具代码管理：svn、git持续集成：jenkins、shell、pythonDocker化：docker、harbor、kubernetes监控告警：zabbix、prometheus日志系统：filebeat,kafka,logstash,elasticsearch,kibana代码管理大多数项目还是通过svn来管理，这里以svn为例，每个项目有3条代码行，dev,trunk,releasesdev：本地开发，一个功能或任务提交后即可开发到dev分支，同时可以部署到dev环境进行自测。将代码合并到releases分支，部署隐藏环境（模拟环境，所有配置，代码等与线上一致）再次返回，返回通过则上线产品。官方环境有些项目是按版本发布的，所以将代码合并到releases后，分支/标签会打上标签，部署到隐测中进行持续集成。这一步的主要工作是根据需求将源码打包成最终的线上工程。大部分作品都有shell和python编写的脚本。来完成，比如从svn中拉取代码，编译源码，合并压缩静态资源文件等，利用jenkins把我们零散的步骤串成一个完整的流程，运维这部分要熟悉，但不要太多Docker介绍Docker是我们整个解决方案中非常重要的一部分，可以方便的部署。所有环境都使用同一个Docker镜像，也保证了环境的统一性，大大减少了开发环境正常运行和线上运行的错误发生。可根据项目负载实时调整资源占用，节省成本。Dockerfile：通过编写dockerfile来打包镜像harbor：充当dockerhub镜像仓库，有web接口和api接口，方便集成kubernetes：kubernetes(k8s)将Docker实例一个一个集成成一个集群，方便镜像分发、升级、回滚、增减副本数，也提供ingress外网访问方式，比较重，但是我们没有用到太高级的功能，只是上面提到的一些基本功能，无需进行k8s二次开发或定制，部署使用即可，运维技术难度不高。监控告警监控告警在整个运维过程中非常重要。可以未雨绸缪，减少故障的发生，加快故障的解决。这块也是运维的基础，不过我介绍了zabbix：宿主机通过zabbix统一监控告警。Prometheus：通过prometheus对Docker容器的运行状态进行监控和告警（暂未完成）。用着没问题，也不用听开发说“xx，帮我把在线日志拉下来”。我们使用的架构是filebeat/rsyslog-->kafka-->logstash-->elasticsearch-->kibanafilebeat/rsyslog：客户端通过filebeat或者rsyslog收集日志。filebeat是go开发的程序，部署起来非常方便。它与Docker是绝配。在我们的Docker基础镜像中，默认有一个filebeat服务来初始化配置文件。后期集成项目代码时无需额外配置。使用rsyslog的好处是大部分系统都有自己的rsyslog服务，不需要安装额外的程序来收集日志，但是rsyslog需要使用omkafka模块向kafka传输数据。omkafka对rsyslog版本有要求。大多数系统需要升级rsyslog版本。很麻烦，所以放弃了kafka：kafka是用来处理日志数据的，但是我们用3台机器做一个kafka集群，一个topic对应多个group，避免logstash单点：从kafka取数据，filter并将其写入elasticsearch。还在疑惑为什么介绍Kafka时一个topic对应多个group？主要是1组对应1个logstash索引，解决logstash单点elasticsearch：存储过滤后的数据，同样使用3节点Clusters，避免单点kibana：可视化工具，方便搜索想要的数据，同事也做各种报表，一目了然总结支持：获得各方的支持，项目成功了一半，烤肉解决不了没有，如果有两个规范：项目多，庞大的系统，一定要有规范，规范是自动化的基础文档：详细的实现过程，如何使用，如何维护，应该保留详细的文档培训：对于jenkins，elk非运维使用的工具应该对用户有相应的培训和分享。当然，项目的各种细节也应该在运维内部共享
