DevOps团队能缓解云迁移问题吗？

　　欢迎各位阅读本篇文章，DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称本篇文章讲述了DevOps团队能缓解云迁移问题吗?

　　正如他们岗位职能说明的那样，DevOps团队的工作人员要比几乎所有其他IT人员更了解云计算。DevOps团队知道如何针对新部署的软件进行应用配置，他们知道如何与旧系统通过接口进行交互。当然，这也使他们非常善于对传统软件实施云计算迁移。

　　DevOps团队的人员都知道传统文件系统、分布式文件系统以及对象存储(例如亚马逊简单存储服务)的来龙去脉。他们还知道如何处理大规模分析应用和非关系型数据库。他们可以帮助用户把现有应用逻辑迁移至可扩展并完全在云计算中运行的服务。

　　企业可以通过在云计算中的虚拟机上运行所有的应用来简化应用从传统硬件到云计算的迁移工作。但是，更好的办法是真正地把所有逻辑业务完全通过网络规模级技术来实现(通常每次一小部分)。DevOps团队能够帮助处理负载平衡、容错、域名系统延迟以及状态检查等问题。

　　此外，DevOps团队通常被要求提交分析报告。这是因为他们拥有所有的信息，他们能够访问所有的底层基础数据，其中包括流量数据和日志分析记录。这种类型的数据在评价应用运行性能和寻找瓶颈所在时时非常有用的。DevOps人员能够帮助针对每一次部署发布进行部署管理和bug追踪。此外，他们还能够有助于确定每个发布的速度变化和性能差异。

　　DevOps团队的强大工具

　　即便是具有最高度功能化的DevOps团队也是需要第三方工具来管理诸如云计算这类的分布式环境。对于这样的环境来说，某些工具是特别有用的。

　　诸如FlowDock或HipChat这样的实用工具能够帮助开发团队的成员互相以及与DevOps人员保持联系。诸如Asana或Basecamp这类服务能够有助于跟踪开发任务以及在应用发布中的注意事项。

　　诸如Freshdesk、Zendesk或Get Satisfaction这样以客户为中心的支持门户网站可让用户直接与管理层或开发团队进行需求沟通。这将有助于触发新的或改进的功能，并确保客户的需求能够得到满足。一个DevOps团队能够帮助建立这些服务，并让团队成员了解相关技术。

　　能够做到这一点的人

　　如果您希望确保有人能够编写出能够经受测试的高质量代码，那么你可能需要在代码发生问题时就让程序员从床上爬起来解bug。而一个DevOps团队并不希望在半夜三更被一个电话叫醒，所以他们希望确保拥有所有的工具，从而确保有尽可能多的任务能够实现自动化实施。

　　如果有一台服务器死机，就应立即更换并，如有可能还需保留所有相关的日志以供日后分析。此时，试图修复服务器将是不明智的;当自修复系统检测到问题时，企业用户可以非常容易地使用一个自动触发的简单API调用来替换它们。而异常检测可向用户提前提出系统中存在的潜在风险因素或泄漏警告。

　　DevOps团队的成员需要成为云计算和云计算服务配置的权威专家。他们需要了解非关系型数据库的优势，如有需要还应知道如何高效地扩展关系型数据库。他们应能够向开发人员展示他们应用的有问题部分，并确定应在哪一种类型硬件上运行应用的每一个部分，从而帮助开发人员实现成功。他们可通过架构图来帮助确保用户系统实现黄金分割——一方面可确保用户应用的容错性能，另一方面也不会让应用运行变得缓慢。他们将能够识别算法，区分能够实现扩展和不能扩展的算法，从而确定资源容量扩展是否适当。

　　知识分享：DevOps现状

　　很多组织将 开发和系统管理划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而 运营部门则更关注IT服务的可靠性和IT成本投入的 效率。两者目标的不匹配，就在 开发与 运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。

　　开发人员经常不考虑自己写的代码会对 运营造成什么影响。他们在交付代码之前，并不邀请 运营人员参与架构决策或 代码评审。

　　开发人员对配置或环境进行修改之后，经常没有及时与 运营人员 沟通，导致新的代码不能运行。

　　开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。想找到必要的配置参数，通常需要尝试很多不同的参数;在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。

　　开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与 运营人员面对的目标运行时环境非常不同：后者对稳定性和性能的要求远胜于灵活性。

　　由于 开发人员平时使用 桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生产环境的运行时系统通常都运行 服务器操作系统上。

　　在 开发过程中，系统在开发者的 本地机器上运行。在 运营过程中，系统经常分布在多台服务器上，例如web服务器、 应用服务器、 数据库服务器等等。

　　开发是由功能性需求(通常与业务需求直接相关)驱动的。

　　运营是由非功能性需求(例如可获得性、可靠性、性能等)驱动的。

　　运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险

　　如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大

　　变更规模越大，风险也越大，因为其中涉及的区域越多

　　由于 运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了 开发人员将特性交付给用户使用的速度。

　　运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。

　　开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。