运营和维护的价值无法支持，填补漏洞和灭火，积极应对变化和风险是运营和维护良好的重要能力。
运营和维护团队通过在云中构建持续集成平台，实现主动响应变更和提高效率的价值目标，并提供应对变更的能力，并提供用户和产品团队提供高效的交付体验。通过这个自我研究的过程，我希望为所有人带来一些灵感。
2010年12月1日，51CTO组织的WOTD软件开发技术世界峰会在深圳中州万豪酒店举行。
峰会以软件开发为基础。高级建筑师顾日奇在创新的运维考察中与嘉宾分享了“云交付之路的持续整合”演讲，为运营自动化与维护建设提供了探索和实践经验。 。
这次交流分为三个部分：
自动化施工流程。
在云中持续集成和交付。
期待智能化的运维。
自动化施工流程。
持续集成构造的底部，如上图所示：
2003年至2008年，互联网时代1.0。我们的互联网业务仅限于官方网站和BBS，服务器是PHP + MySQL。
2009年至2011年，互联网2.0的时代。这时，我们有一个真正的服务器和操作，其中包括：LVS架构模式和主从复制数据库的设计。但我们的业务仍在单一的IDC上运行。
从2012年到2013年，互联网时代2.5。在互联网业务中，我们增加了应用中心，多媒体和O2O。
在体系结构方面，我们对主从数据库进行了划分，分区和路由。
在缓存方面，我们引入了Redis集群并添加了分布式存储MFS（MooseFS）。
同时，出现了一些相应的支持服务，如搜索引擎，多个MQ（Message Queue）等。
2014年，它进入了互联网3.0时代。这个时代的一个重要里程碑是我们的互联网业务已成为主要业务之一。
运营和维护面临的发展挑战。
在Internet 1.0到3.0的演变过程中，随着业务的快速增长，我们的运营和维护面临着一些挑战，主要来自质量，效率，成本和安全四个方面。
在质量方面，衡量质量的最佳方法是观察其可用性指标。一般来说，我们分为直接和间接。
直接指标，我们可以从监控中看到网络，服务，应用程序和系统的可用性；间接指标，我们可以标记一些体验参数，如职业速度，也可以标记一些商业参数，如说手机短信的到达率。我们的商业可用性非常低，没有完善的监控系统。与此同时，我们的监控状况也令人困惑，不仅覆盖率低，而且常常导致一些误报，漏报，虚假陈述等。这直接导致了所有监控的难以置信。
在效率方面，效率是衡量运营和维护平台功能的标准，主要体现在服务器的交付，线路的几个变化以及我们及时发现的故障。我们经常提供和更换，但我们不会将流程与自动化相结合，因此整体效率很低。
在成本方面，它主要反映在一般业务规划以及交付能力的改进和优化中。由于我们不完善的流程和不透明的工作，无法评估公司需要多少容量。因此，“填孔”，“灭火”，“背锅”已成为我们运营和维护的“自制食品”。
在安全性方面，它是整个互联网产品的生命线。因此，在产品开发的早期阶段，我们已经开发了一些安全标准和系统。
随后，建立了一个相对完整的安全系统，以通过系统，数据和应用程序等维度反映团队对安全问题的控制。
运行和维护平台的状态。
我们已经建立了一系列基于价值的系统。从功能的角度来看，它主要分为以下几个系统：
资源管理系统，我们通过KVM + Docker在云中构建一个平台。基于云平台，我们建立了虚拟化网络和计算资源管理系统，并通过CMDB进行管理和控制。
配置管理系统，我们有LVS，CDN，DNS等管理系统。与此同时，我们向外界开放了一些API。这样做的好处是我们可以优化相应的权限，以便可以在我们的系统中管理所有操作。
自动化系统，我们拥有自己开发的工单，记录，发布，操作和维护通道以及自动检测系统。这些可以为交付和操作变化提供效率改进。
监控和容量系统，我们有基本的监控系统，个性化监控，业务监控和容量。容量系统可以帮助我们评估公司需要多少资源，并可以为该公司实施成本控制。
安全系统，我们所有的操作都是通过堡垒机器记录下来的。这将允许我们审核用户的不同操作。
通过漏洞管理系统和自行开发的WAF系统，我们可以自主发现攻击和各种漏洞。然后，进一步将漏洞信息导入漏洞管理平台进行迭代，修复和跟踪。
编辑平台的演变。
我们的发布平台经历了三次发布会：每周发布，每日发布和自我发布。由于业务开始时很简单，我们使用手动方法。
后来，随着业务的大幅增长，手动操作必须由自动化工具取代。例如，我们使用自动化工具向服务器提供各种命令，脚本和任务。虽然这解决了一些问题，但其整体出版效率仍然相对较低，成功率不高。
针对这一问题，我们与综合业务发布平台的CMDB的“商业树”相关联，并已制定了一些规范和相关指标，以提高成功率和容错的版本。
为了使发布更加灵活，我们已经为每个业务部门颁发了权限，不同业务部门的负责人将进行审核。因此，我们的整个启动过程不需要运营参与。
让我们看看发布平台的当前状态。我们的功能是更多的发布策略，例如桌面发布，只需单击即可重新启动并发布静态文件。
同时，有许多类型的兼容版本，例如Jetty，task，chef，PHP，C ++等。
如表中所示，我们的成功率保持在98％以上，我们的桌面出版率也在不断增长。在出版过程中，我们有超过90％的公司不需要参与运营和维护。
交货过程
我们的交付流程可分为三个环境：开发，测试和生产。开发包括在本地编写代码，通过自检，然后将其发送到页面。
由Jenkins和WTS Redmine打包。所述测试将在自动或手动验证之前在测试环境中实施。
在操作和生产环境的维护，我们将准备一个基本的环境提供的多个记录收集，报警监控和应用程序的快速扩张自动部署。
这里存在微妙的平衡：它要求我们拥有相对完整的技术环境，负责自治框架的人员必须尽可能稳定。
这将有助于我们获得良好的文档和技术沉淀。否则，一旦平衡被打破，例如，一些过程不遵循，或者我们的相关人员的输出，或者如果我们的框架是更新太快，所有的交付将还没完成。
那么，交付过程中存在哪些问题？我们通过以下方式总结：
在质量方面，我们发现有些代码没有完成单元测试，我们需要统计其相应的覆盖范围和错误数量。
在效率方面，自动化实施，自动化测试和自动化施工的实施分布在不同的职能部门，导致“墙”尚未开放，因此我们无法实现精细化操作。
沟通成本高，交付复杂。
如果我们的代码是安全的并且可以通过安全测试，那么应该解决这些问题。
那么，我们追求什么样的价值框架？如图所示，底部是一个开发框架平台。
首先，我们的云平台需要自动化环境，以便我们确保我们提供的环境是标准化的。接下来是总体发展框架。我们的技术委员会继续实施基本开发框架和架构，以确保我们拥有基本的技术堆栈和环境自动化流程。
交付管道的基本原则是使标准化流程自动化。我们开发了一系列工艺和规格，以实现可靠和可重复的连续输送流程。
该过程将包含大量内容，例如：并行开发，编译和编译，单元测试和系统测试以及验证阶段的集成测试。
最后，在发射和运行阶段的生产交付意味着恢复发射和随后的生产监控。所有这些过程都在这个管道中进行。
另外，系统是一个多角色平台，会有一些协调角色的开发人员和部分运维测试人员进行协调，使平台能够使整个团队受益。
在云中持续集成和交付。
建设规范化。
我们的自动化分为三个阶段，即标准化，自动化和智能。
在标准化方面，我们有硬件标准化，组件标准化和技术堆栈标准化（例如我们使用的协议类型），以及监控标准化。
在测试自动化方面，我们将涵盖广泛的内容，包括：单元测试，单元覆盖，测试访问标准，例如，如果在交付过程中允许某些错误。
在施工过程中有两种替代技术解决方案：
开源，我们可以使用Docker执行与环境自动化标准相关的操作，并使用ES来完成注册系统。但该计划对我们现有的系统产生了更大的影响。
基于现有平台的各种系统实践，我们在发布平台和CMDB上制定了一些规范和流程。
最后，我们选择第二种选择。当然，在程序实施过程中，由于需要更多的耦合平台，我们也发现了很多阻力。
鉴于这些平台分散在PMO，测试，运营和维护等不同部门，开放这些部门，我们在开发过程中使用了不同的规范，例如：
在操作和维护的部门，发布平台将包括涉及到机房的规格，包括在服务器上位于机房的服务器，服务，服务器环境的规模灰色和属于生产环境的服务器。所有这些都通过CMDB业务树进行操作。
在开发办公室，开发人员可以使用一些完全开源的平台，如Jenkins。由于它是完全开源的并且未经过修改，因此其各种操作规范和某些名称的标识可能与我们的业务树不对应。所有这些都增加了转型的难度。
因此，在平台的建设中，我们的一个实践是统一入口。由于Jenkins已打包，我们可以完全调用Jenkins API将此包装集成到自己的平台中。同时，我们还将需求信息与Redmine同步。此外，为了实现错误的输入和跟进，我们还在此平台中集成了Errors入口门户。
这不会对我们以前的运营产生太大影响，但也会解决相互需求和错误数量的问题。
最后，由于它是一个多用户平台，我们还必须输入并同步系统中的相关人员信息（包括开发，测试，操作和维护等）。
自动化施工
让我们看看持续集成的过程：
第一个是需求阶段，例如：我们的一个产品运营商将其要求输入系统。然后，开发负责人分析或预览需求并评估交付日期。
然后进入开发阶段，包括编写代码，发送代码和编译编译。在构建时还有一些静态分析，以及代码覆盖。
在测试阶段，系统将实施测试环境并执行一些自动化测试，包括各种安全测试和性能测试。
当然，我们还会进行手动验证，以验证其是否符合测试访问标准。如果出现问题，该过程将返回给开发部门，他们必须重新发送代码然后执行访问过程。
如果在此阶段没有问题，公司的开发经理或操作和维护人员将开始修改版本并在灰度环境中发布代码。
在灰度环境中，我们还需要执行一些自动化测试来验证服务的安全性。只有达到其接口传递速度，我们才能最终将其发布到生产环境中。
您可以看到，从项目要求到启动阶段，我们都在自己的平台上运行，整个交付流程实现了详细的进度管理。
让我们看看解放的过程：
第一个是环境验证，这里主要检查服务器上是否有一系列用户目录，以及一些相关权限。
同时，我们将文件从包装平台提取到IDC。
然后你需要关闭监控。因为在服务实施期间会有短时间不可用，这将激活监控警报，因此，我们将监督相应服务器的关闭。
当然，Web也将处于脱机状态，因此新的流量将不再流动。
然后，服务停止以确保文件不忙。
我们进行文件更新操作。
我们在前一个过程完成后启动服务。
启动服务后，我们仍然需要执行监控和检查。此检查的主要目的是确保我们更新的服务可用。
然后，Web启动，我们将服务添加到LVS集群。
最后，打开监控。
在之前的发布过程中，我们将针对某些业务功能启动并行或序列化功能。这样，在保证成功率的前提下，我们可以进一步提高出版效率。通过这个持续交付平台，我们可以使用它来支持快速和通用的互联网迭代产品开发模型。
我们可以实现预迭代要求的规划，以及确保迭代的开发，测试和启动，以及迭代后审查。
通过收集信息和数据，我们可以看到系统是否在代码质量方面遇到严重问题，以及是否存在任何阻塞。
此外，纠错情况也很明显。我们还可以获得代码覆盖率，代码测试批准率，性能测试，安全测试和接口测试数据。
上海IT外包服务网 链接：http://www.linemore.com
中文
电话咨询
微信咨询
公众号
