첫째, 지속적인 배포
1. 상태
더 혼란 버전 관리, 제품 관리 혼돈의 긴 기간으로 이어지는 연속 배포 프로세스의 표준이 확립되어 있으므로 온라인, 테스트 커버리지가 더 많은 트래픽 장애, 복잡한 문제 해결을 상승 후, 종합 아닌 온라인. 운영 및 유지 관리, 테스트, 각 반복 시간의 개발자 버전, 철야 경험을 통해 갈 필요가 있으며,이 여전히 라인에 선 결함의 많은 다음 날이 될 것입니다.
2. 고충
자동화 된 출판 시스템의 범위는 낮다.
· 어떤 프로세스 표준화는 발표하지 않는다.
; A)는 품질 문제 무시하고, 오직 민첩성에 초점
b)는 변화 증가 실패율 자주 리드;
C) 다중 언어, 혼란 릴리스 관리 제품의 개발, 복잡한 게시를;
· 보안 문제가 쉽게 간과.
둘째, 도구 소개
1. 소금 스택
의 오픈 소스 구성 관리 도구 ZeroMQ 기준으로합니다. 선택 saltstack, ansible주고 손가락의 사용으로 인해 ansible SSH 기반 통신 명령 큐의 메시지에 기초하여 500 개 단위, 안정성 및 속도 SSH 프로토콜 우수한 방식 중 전송 호스트의 제어 후에되는 이유 . 또한 saltstack 이유에서 직선 선거, 특히 자바 및 닷넷 공존의 경우, 개발 지원 서비스에서 다른 기술 스택 평행 상황 있다는 것입니다, 창문 saltstack 지원은 상당히 더 ansible보다. 기본 플랫폼으로보다 쉽고 도구를 게시.
그리고 SaltStack를 기반으로 빌드 자동화 플랫폼은 곡물, 기둥, 주 세 가지 특징, 기본 환경 구성 정보를 얻기 위해 사용 곡물, 환경 정보의 정의에 대한 기둥, 상태가 게시 레이아웃 파일을 게시와 배포됩니다.
2. Artifactory
전체 언어 제품 창고 관리 소프트웨어, 오픈 소스 에디션과 엔터프라이즈 에디션 이가지. 오픈 소스 에디션은 제품 관리를 받는다는 지원, 기업 버전 관리 제품으로는 전체 언어를 지원, 취약점 스캐닝 기능을 제공하는 고 가용성 배포, 일치 NVD 및 vulnDB 데이터베이스를 제공하고, 메타 데이터 관리를 지원합니다.
셋째, 상기 통증 점수의 해결책
1. 자동 해제 낮은 범위
도구를 게시 통합 멀티 플랫폼 호환 배포를 구축함으로써, 표준화를 달성하기 위해 도구를 게시 전통적인 방법 쉘 스크립트의 사본을 대체 할 수 있습니다. 상태 속성에 의해 기본 서비스의 SaltStack는 수동 조작의 크로스 플랫폼 출판, 서비스 시작 및 정지, 파일 배포, 구성 배포, 원격 관리 호스트의 90 % 이상을 달성했다. Artifactory를 통해 상태 할당 파일, 원격 명령 실행, 제품 및 구성에 액세스의 SaltStack의 사용은 라인을 해제해야합니다.
JSON 형식으로 배포 플랫폼의 주요 프로그램은 안무 작업을 수행하는 플랫폼 스케줄링을 통해 최종 saltstack 프로필 YAML JSON 파일로 변환됩니다 yaml.dump (sls_json)에 의해, 릴리스 과정에서 설명했다.
다음과 같이 변환 YAML 파일 형식은 다음과 같습니다
2. 규격화 게시 프로세스
· 备份
发布任务编排的第一步就是备份，备份需采用本地备份加异地备份两种机制，本地备份用于快速回滚，异地备份用于环境重建。
·切流量（蓝绿部署）
对于服务，尤其是有状态的服务，需要在注册中心中进行节点下线，确保本节点所有处理结束后，再进行部署。
对于页面，需要在负载均衡上将节点注销，对没有流量的web页面进行部署操作。
·部署
通过saltstack的sls特性，编排部署文件，对多个部署任务进行统一进行发布。
部署时我们希望可以在部署页面查看到类似下述信息，如：部署包对应的需求id、部署包对应代码的提交信息、部署包自动化测试的通过率、部署包的代码扫描结果、部署包的安全扫描结果、部署包人工测试的结果等等。运维人员需要在发布过程中看到此类信息，来明确包是否通过了所有质量关卡、具备了上线条件，从而判断此次上线是否可以继续进行。这里我们使用了Artifactory的元数据功能，用于记录软件包诞生的整个生命周期的信息，并通过api方式对接到发布平台。给运维人员一个完整的包的信息记录。
·自动化测试
此处自动化测试主要可以理解为检测服务端口通信是否正常、回归线上功能是否可用、缺陷是否被修复、新特性是否部署完成等。同时此处需要预热服务及站点，通过自动化的测试打通业务流程。
·流量回归（金丝雀）
部分真实流量切换到已经部署完成的应用上，通过全链路日志追踪或监控指标反馈来初步判断新上线应用是否健康运行，并将此结果作为后续发布或回退的依据。
·部署补全（滚动发布）
在使用低谷时间将流量牵引到已部署完成的应用上，同时将其余应用升级。
·变更管理通告。
上线成功后需要及时的通知大家线上版本已变更，产品经理需要及时更新文档，运营人员需要及时对用户进行告知。
·回滚
任何发布都需要考虑回滚方案，对于单个应用需要回滚到一个指定版本；对于多个应用，需要明确一个回滚集，通过发布时的编排任务指定回滚的编排任务。对于数据库等更新，如果回顾复杂，则需要在升级方案制定前就明确回滚方案或在业务中做好版本兼容。
3. 建立统一的制品管理仓库
大多互联网公司已经对源码仓库有了统一的管理，但对于制品依然处于一个原始的管理状况，比如使用ftp以及每种语言开源的管理仓库。这里遇到的问题是，运维人员需要投入大量的精力维护不同的包管理平台（如ftp、maven、nuget、pypi、docker镜像中心等）。浪费掉大量运维团队的人力成本之外，也极度复杂了发布流程。发布人员需要在不同的平台获取上线的包，导致发布流程混乱，发布平台配置混乱。并且大多数开源组件均不提供高可用能力，一旦硬件或软件出现故障，都将严重的影响发布效率。
为了解决这种问题，我们采用Artifactory来管理所有语言的制品仓库。与统一gitlab一个道理，我们把整个公司的制品统一管理，成为对接发布平台的唯一包来源，从而规范了发布流程。
4. 漏洞扫描
目前安全团队扫描大多是在服务部署上线后进行，这种情况下和容易造成由于版本有安全漏洞导致的整个迭代废弃，所有包需要重新编译，重新经过测试流程以及上线过程，浪费掉大量的时间，降低迭代的速度。
解决办法是将漏洞扫描步骤前置，在制品包构造编译的时候，乃至开发人员code代码的时候就对外部引用、内部公共库进行漏洞扫描，一旦匹配到高危漏洞，直接把提交或构建终端。如果一定要继续构建，那么可以将扫描结果记录到制品的元数据中，供测试人员，运维人员查看。目前JFrog Xray等安全扫描故居提供此类能力。也可以使用开源软件，如cvechecker，在编译流水线中对包进行扫描，防止由于安全漏洞造成的整个迭代失败。
四、 后期完善
1. 设置度量体系，提升发布质量
敏捷开发模式下，开发人员和测试人员往往是汇报给同一位管理人员，出于快速迭代线上功能，往往有些团队会投机取巧、将没有测试完整的包发布到线上进行测试。该种问题的直接表现是，为了解决一个bug，可能多时间多次对同一个应用或页面进行hotfix或发布新版本。这样做是十分危险的，置线上业务稳定于不顾。为了避免此类情况发生、我们可以采用一些措施或规范来约束开发团队。例如：
上线后触发新bug数量
短时间内对相同问题发布次数
由于上线原因造成的P5-P0级别故障的数量
上线后故障恢复时间
上线后回滚的次数
非上线时间内紧急上线数量
…
通过收集上述数据，每月或固定周期对各个团队进行考核。并对发布状态复盘，通过制定规约，评估团队的交付质量及交付能力，挖掘团队中的发布问题及痛点，从而提高发布质量，减少线上故障率。
2. 制定度量标准，进行发布质量考核
每团队初始分为100分，每月重置，每月用此分作为迭代质量的一项标准，分数不挂钩kpi考核，只用来驱动开发团队去提高效率。
评判为两个维度：项目组发布稳定性得分、服务（站点、app、微服务等）发布质量得分
·非上线时间发布hotfix（项目组减1分，服务减1分）
·代码类hotfix，同一项目每天发布超过3次（项目组减1分，服务减2分）
·hotfix发布失败或回滚（项目组减2分，服务减2分），发布是否失败，由运维团队认定。
·数据库等脚本异常或执行失败（项目组减1分）
·每月服务发布数量（取top5，服务按排序减5到1分）
·由于hotfix原因造成P2级以上的线上事故，项目组减5分，相关服务减5分
·项目组本月hotfix量如超过前3月平均值的30%，减10分
3. 变更管理
在google的SRE体系中，变更管理是DevOps体系中最为重要的一个部分。根据以往的经验，90%的线上故障是由于线上变更导致的，该变更原因包括软件、硬件、环境等所有因素。建设变更管理体系目的就是为了快速定位线上问题，止损由于变更造成的线上故障，及时通知相关人员做好故障预防工作。所以，变更管理体系也是需要我们重点去建设以及完善的。
落地方式包括但不限于下述几点：
·运维人员、对应的开发及测试人员、产品经理等微信通知
·大屏滚动播放最近的变更记录
·变更记录同步到监控系统
五、 总结
总结为一句话，虽然在敏捷开发模式下、产品、开发、测试团队都在小步快跑，但运维必须有自己的原则，一定要对整个上线流程制定规范、对DevOps工具链进行统一管理。
线上稳定大于一切！