标签归档:DevOps

Jenkins与持续交付的诸多问题

如果您使用软件,您可能已经意识到软件交付的实践在今天远非完美。查看我们上个月关于自世纪之交以来软件开发演变的文章,原因有些。在那篇文章中,我们解释了导致我们进入当今软件世界的道路,以及为什么这个世界可能达不到我们的期望。

这篇文章是我们关于进入詹金斯后世界的系列文章的第二篇。在这里,我们更详细地看一下流行的工具和流程,包括但不限于Jenkins,它们阻碍了我们从软件的必杀技。

我们喜欢詹金斯!

需要明确的是,我们并未将Jenkins视为当今软件交付领域的唯一问题。我们实际上认为詹金斯是一个很棒的工具。但是,Jenkins和其他持续集成(CI)服务器并不总是正确使用。软件交付团队倾向于在如何部署Jenkins和类似工具时犯错误。结果,他们采用低效的做法,削弱了他们获得或保持敏捷性的能力,并失去了采用最新技术创新所需的灵活性。

詹金斯的问题

最终,这些问题的根源不是来自特定工具,而是来自文化错误。

问题1:詹金斯插件太多了

插件不一定是坏事。实际上,当它们被正确使用时(这意味着将功能扩展到软件平台所需的核心功能之外),它们就是很好的资源。它们为用户提供了为他们使用的工具添加额外功能的选择,而不需要他们在不希望使用这些功能的情况下将资源专用于这些功能。

但对于Jenkins而言,插件不提供对可选功能的访问,这些功能超出了使用该平台所需的核心功能。相反,Jenkins要求团队使用插件来实现在许多情况下非常基本的任务。

例如,如果你想为Docker环境构建 – 这是一个非常常见的用例 – 你需要一个插件如果你想从GitHub(另一个非常常见的任务)拉,那么你需要一个插件如果您需要PAM支持,则需要一个插件。

可以肯定的是,Jenkins的1,500个插件中的许多都提供了并非每个人都需要的功能。它通过插件提供完美的意义,例如,PagerDuty或Azure存储兼容性,因为许多用户可能不需要这些功能。

但是你需要在Jenkins中插件来做任何事情都是有问题的 – 而且这不仅仅是因为它意味着软件交付团队必须花时间安装和配置它们才能开始工作。这里更大的问题是Jenkins的大多数插件都是由第三方编写的,质量各异,可能会在没有通知的情况下失去支持。

构建基于第三方插件的软件交付链并不是确保可用性或稳定性的好方法。

问题2:Jenkins不是为Docker时代而设计的

虽然CI服务器通常是现代DevOps会话的一部分(并且确实是DevOps工程师的许多重要工具之一),但它们实际上是一种相对古老的技术,可以追溯到2000年代中期 – 早在任何人想象容器之前和微服务作为软件部署的首选基础设施。

因此,传统的CI服务器无法帮助团队充分利用Docker容器等下一代基础架构。他们通过多个插件很笨拙地与Docker集成。实际上,Jenkins 在其名称中使用Docker的插件不少于14个许多用于特定供应商的Docker相关平台,但其中六个用于核心Docker平台。

从许多方面来说,Jenkins与大多数其他CI服务器一样,是在裸机服务器和虚拟机时代构建的。事实上它支持Docker支持。在越来越多的Docker本地环境中,这不是CI服务器运行的好方法。

问题3:Jenkins不能很好地支持微服务

就像Jenkins和大多数其他CI服务器诞生于Docker之前的时代一样,它们也在微服务变得流行之前出现。

当然,有些人在2000年代使用面向服务的架构(SOA),同时Jenkins首次使用。自20世纪80年代以来,微内核等概念就已存在。但是直到Docker出现并使微服务易于实现,实际上已经部署了很少的微服务平台。

所以你可能不会期望Jenkins能够很好地支持微服务 – 事实上,它并没有。Jenkins缺乏对同时集成和测试多个服务的支持。这是微服务环境的基本功能。

除非您计划投资多个管道的开销(每个微服务一个),Jenkins在帮助您开发下一代微服务应用程序方面做得很差。

问题4:CI!= CD

Jenkins和CI服务器的最大问题很可能是软件交付团队有时会将持续集成与持续交付(CD)混为一谈。

事实上,CI和CD是不同的东西。CI是CD流程的一部分,但要实现完整的CD – 这应该是任何旨在优化其工作流程的软件交付团队的目标 – 您需要的不仅仅是CI服务器。

CD还需要将自动释放自动化到您正在使用的环境中,无论是什么。它需要可以自动执行不属于CI服务器范围的软件交付任务的工具,例如步骤CD需要通信工具和渠道,以使软件交付团队能够无缝协作。

当组织设置CI服务器并立即考虑他们的软件交付现代化工作完成时,他们犯了一个大错误。

改变詹金斯世界的文化

为什么熟练的软件工程团队会犯这样的错误?这并不是因为他们没有智能或无法跟上最新的创新。

相反,问题在于错误的尝试模仿最大,最有效的软件交付操作,如谷歌和Netflix。这些组织着名地利用开源工具链和大型基础架构,构建令人难以置信的敏捷软件交付管道。

是什么使这些公司能够构建这些管道不仅仅是他们部署的工具,还有他们的文化。仅使用与Google相同的工具,您无法像Google一样高效。

较小的组织并不总是意识到这一点。只有当他们拥有正确的文化理念和流程时,他们才能克服像Jenkins这样的工具的局限性,并优化他们的软件交付管道。

没有工具链是完美的,但是当您实施正确的文化时,您可以实现完美的软件交付(或至少接近它)。

如果您的软件交付方法仍然只围绕Jenkins构建,那么您无疑会错失更好的机会。实现这些机会需要文化变革。在本系列的下一篇文章中,我们将研究具有前瞻性思维的公司如何将新工具与新的软件交付文化相结合,以超越我们长期努力解决的以Jenkins为中心的世界的低效率。

https://thenewstack.io/many-problems-jenkins-continuous-delivery/

打击警报疲劳:如何唤醒警报策略

如今,工程团队面临着保持系统平稳运行的必要性。这是因为企业与数字客户体验之间的界限正在缩小 – 当应用程序成为企业时,任何缺乏完美用户体验的东西都意味着要达到顶线。

在这种背景下,声音警报策略现在几乎对每个工程团队都至关重要。根据最近的一项调查,58%的DevOps专业人员报告依靠五个或更多可观察性工具来确定性能问题的根本原因,这意味着他们会针对每个问题对多个位置的数千个警报进行排序以找到答案。由于无法始终监控系统健康状况的各个方面,因此智能警报策略可以帮助团队更有效地运营,并将注意力集中在最需要的地方,从而保持业务平稳运行。

但设置警报并不总是像看起来那么简单。为了做到这一点,团队不仅要应对表面下方存在的庞大复杂性,还要对抗“警报疲劳”,或者在过于频繁时忽略通知的倾向。两种情况下的关键是在节奏和紧迫性之间取得适当的平衡。为了帮助您的团队建立更好的警报策略(并在晚上睡得更好),这里介绍我们如何应对Scalyr的挑战

警报结构

首先,关于结构的一个词。在最高级别,警报围绕三个关键支柱设计:指标(您要监控的绩效指标),比较报表(即“大于”,“小于”,“等于”)和阈值(关键值为您)想要比较指标)。

例如,要监视CPU使用率的意外峰值,可以设置以下警报:如果过去15分钟内的平均CPU使用率大于过去的24小时平均值,则触发警报。

阈值

创建警报时,通常可以通过建立阈值来启动。可以将三种类型应用于警报:固定,基于状态和历史。

固定阈值,顾名思义,当性能水平超过某个静态预定级别时触发警报。在测量具有硬限制的性能指标(如CPU使用率或硬盘空间)时,这些是设置和最佳工作的最简单阈值。

基于状态的阈值也简单明了。它们识别系统状态的变化 – 例如,“运行”或“停止” – 并且主要用于监视应用程序进程以发生意外停机。

历史门槛稍微复杂一些。也被称为“滑动窗口”,这些阈值将度量的当前值与其过去的值进行比较。换句话说,监视一个特定的时间段(例如15分钟的窗口),随着时钟滴答而继续移动。例如,基于历史阈值的警报可能显示为:如果15分钟的平均CPU使用率大于24小时前15分钟平均CPU使用率的120%,则触发警报。这里的想法是在滤除噪声的同时识别给定度量中的突然尖峰。

在此主题上,在设置警报时包含“宽限期”也很有用。换句话说,添加一个规则,防止警报被触发,除非它被触发持续一段时间。这有助于滤除小的像差并识别长期活动。

度量

一旦确定了阈值,就需要确定支持警报的指标。每种警报策略都需要涵盖五个关键指标类别:容量,带宽,状态,速率和事件参数指标。

容量指标监视具有固定和已知容量的系统组件,例如磁盘空间和可用内存。如果某些东西可以“填满”或“耗尽”,通常用容量指标来衡量。达到容量时,系统会中断,这意味着阈值应设置在最大容量以下。当击中容量的后果具有严重破坏性时,应将阈值设置得特别低。

带宽指标衡量系统内的流量。例如,网络利用率,CPU使用率和磁盘吞吐量。这种类型的系统活动本质上通常是高度可变的,因此请考虑将警报基于移动平均线。例如,您可以将其设置为测量30分钟窗口的平均使用量,而不是通过查看最新测量来监控网络使用情况。

状态度量标准具有用于监视系统状态更改的不同值,例如“正在运行”或“已停止”。这些系统状态度量标准通常与基于状态的阈值挂钩。

费率指标用于衡量某些事件发生的比率。换句话说,在特定时间段内发生的事件的数量。例如,“每秒请求数”,“每秒错误数”,“每分钟登录尝试数”等。对于可预测的指标,历史阈值最好。对于不太可预测的那些,将阈值基于历史高点或低点通常是一种合理的方法。

事件参数度量基于事件的某些可测量属性,例如响应时间或请求大小。该指标通常用于监控和报告某段时间内所有相关事件的平均值。您为事件参数指标设置的阈值与速率指标的阈值类似 – 使用可预测指标的历史阈值,以及不可预测指标的固定阈值。

通知

有了正确的警报阈值和指标,下一步就是构建一个系统,用于在出现问题时接收通知。这一步至关重要。您可以拥有世界上最好的警报参数,但如果警报没有到达您,它们将无法发挥作用。

现代DevOps环境提供了多种选择。例如,现在可以将警报存储在数据库中并通过电子邮件以每日批次,立即通过电子邮件发送,通过SMS或电话发送或其某种组合来发送。诀窍在于确定哪种交互模型最适合您的团队。

一般来说,紧急警报应该是设计中断的。他们需要立即引起你的注意并传达问题的紧迫性。出于这个原因,在相同的度量标准,不同的阈值和不同的通知方法上“堆叠”警报通常也是有意义的。这里的想法是随着问题变得更加紧迫而升级警报。

警报远远超出了眼睛。设置声音警报策略需要考虑三个关键支柱:阈值,指标和通知。随着应用程序正常运行时间成为每个企业的关键任务,现在花时间为您的应用程序环境和团队找出正确的组合可以发挥重要作用。

https://thenewstack.io/fight-alert-fatigue-how-to-wake-up-your-alerts-strategy/

DevOps所需的技能

除了我们最近的博客“ 如何成为一名优秀的DevOps工程师 ”之外,我们还看到一些DevOps领导者分享他们关于成为DevOps专家所需的关键技能的想法,我们在此列出。

了解质量保证流程:质量保证有助于计划和控制开发过程,以防止项目期间和任何中断时出现严重问题。DevOps有志者应该知道如何根据场景进行分析,影响,影响的位置。

有能力的通才系统管理员:需要了解软件的方式和行为,以便部署和解决问题,并且了解多种编程语言是一个额外的加分点,它有助于脚本或日常任务的自动化。

熟练的编程:应该知道如何开发大型,健壮的应用程序,如何编写高质量的代码,使用哪些工具,框架和库,如何有效地克服障碍。

了解SDLC:应该完全了解软件开发生命周期(SDLC)的工作原理,不同的模型,不同模型之间的差异,每个模型的优缺点等。

技术专长:应具备建立DevOps友好基础架构所需的意识和技术专长。

软技能:应该需要软技能来推动业务的广泛采用,从技术到管理的各个层面。

最新:应该是技术上所有新事物的最新版本。接触人工智能和机器学习等趋势是一个额外的优势,因为它们可能会在未来几年对DevOps的未来产生巨大影响。

找到具有上述技能的人是非常困难的。

DevOps更多的是关于我们工作的原则,而不是关于工具或工作角色的原则,这是团队的努力。DevOps是关于预先构建流程的,以便像变更控制这样的东西或多或少地自动化,这意味着工程师可以识别问题并以极快的方式推送修复。雇用聪明的人以正确的工作和学习态度总是好的,而不是按照他们以前做过的事情的清单。显然存在DevOps技能组短缺,但公司可以做的是,构建自己的原则和实践形式,并培训内部员工(系统管理员和软件人员)以相应地学习DevOps技能。

自动化(或其他)快速云部署,亚马逊每11秒发布一次新的软件

您的IT和DevOps团队今天的移动速度有多快?无论答案是什么,可能还不够快。这不仅仅是我的观点 – 全球接受调查的CIO中有近90%认为,无论他们现在发布新产品和服务更新的速度如何,他们都需要在不久的将来更快地将其推出

这引发了全新的担忧:是否已经推出了新的功能和新功能,以至于IT尚未准备好提出有问题的,错误发布的前景?这些CIO中有四分之三的人似乎也这么认为!

当像亚马逊这样的公司每11秒发布一次新的软件更新时,难怪企业会感受到持续的压力,要求他们踩到天然气并将其保留在那里。但要紧跟这种创新速度更快的压力,并以不损害用户体验的方式这样做,需要进行一些内部创新 – 即通过建立持续创新和持续交付的渠道。

持续的管道使IT和DevOps能够更少地关注日常故障排除,更多地关注大图创新。但是,如果不首先投资自动化,你就无法获得这条管道。

自动化性能反馈

为了使企业能够可靠地为其用户群提供持续创新,而不会让客户体验处于风险之中,他们需要实施一种自动化的,以反馈为中心的文化。这需要通过内部和外部来实现。

例如,当开发人员团队正在开发新功能或服务更新时,需要在公司内部和外部对其进行严格测试。这可以通过A / B测试和早期访问beta周期等手段的组合来实现,以征求早期反馈并将其纳入开发周期。通过在开发早期自动建立对新功能的反馈,您可以将可能不会出现的潜在问题扼杀到过程的后期 – 或者因为反馈迟到而导致整体交付延迟(让您落后一步)您的竞争对手的速度有多快?或者因为这些问题根本没有被发现,您的团队最终会推出一个错误的发布版本。通过在整个技术堆栈中自动执行性能和依赖性分析,

构建一个可靠,一致和自动化的基于事实的反馈循环过程,在发布之前彻底测试新的创新,然后利用额外的反馈,以便将来证明更多的版本,有助于创建一个自给自足的持续创新和交付给您的最终用户。

通过信任建立反馈循环

但要达到这一点,完全需要其他东西:信任。希望创建持续交付模型的IT和DevOps团队需要首先在其组织中培养信任文化。这可能是企业在尝试建立连续管道时面临的最大挑战。

信任是双向的。IT团队需要知道他们可以依赖于每个可以按时,按时,按照用户期望和竞争对手设定的标准交付的高质量,具有发布价值的构建。与此同时,在这些团队中工作的人员也需要接受事情失败,特别是在CI / CD模型的初始阶段。而且,我们如何应对这些失败和错误至关重要 – 不是惩罚,而是利用它们作为学习经验,继续进一步改进并确保通过自动补救的交付过程 – 排除这些类型的失败从再次发生。

持续集成和交付不仅仅是软件挑战; 他们也是文化挑战。企业 – 无论是在IT还是整个企业 – 都需要敏锐地意识到他们在创建一个培养开发人员信任的环境中的责任,创建强大的自动化反馈循环,从而产生强大,高质量的功能和创新。

可以保持连续的连续管道

提供更好的软件 – 最终用户所需的各种版本和体验以及竞争对手所提供的 – 需要扩展DevOps以便以云的速度移动。这需要自动化。

自动化的持续交付管道使开发人员能够发布新的创新,通过基于事实的反馈循环周期进行测试,不仅速度更快,更一致,而且可以确保性能问题早期得到解决和修复。转变为连续的管道模型是允许创新以当今企业云环境所需的速度发生的,并确保开发人员能够在流程早期识别和修复潜在问题,以便推出新产品或功能正在满足您和您的用户 – 高标准。

在一天结束时,实际上没有办法解决这个问题:如果企业希望能够满足客户的期望,他们的DevOps团队需要投资建立自动化的连续管道。基于反馈回路基础的连续创新模型,能够自动修复性能问题,并以持续交付的节奏交付,是企业以云速度移动的最佳工具。

监控您无法忽视的指标

随着DevOps运动的兴起,人们开始关注Web应用程序监控工具。这是一件好事。监控Web应用程序(特别是在生产环境中)通常是事后的想法 – 通常在发生一些事件后才会实施。到那个时候,价值已经失去 – 无论是崩溃,性能不佳还是安全漏洞。

拥有强大的监控策略可收集有关Web应用程序运行状况的信息。在解决您的应用程序问题时,将硬信息用作指南会产生奇迹。然而,可能有太多好事。信息太多会导致信息疲劳,这与没有足够的信息一样糟糕。如果您的应用程序中显示的信息太多,那么它最终可能会被调整掉。发生这种情况时,就像没有监控一样。

在本文中,我将讨论一些需要考虑进行监控的最重要指标。此外,我们将介绍用于无缝提供信息的信息呈现方法。让我们开始吧。

选择最重要的指标

如上所述,任何无法采取行动的信息都是您需要消耗的精神体重。充其量,你只会忽略这些信息,最糟糕的是,它会将你的监控变成一个混乱的混乱,并没有提供太多的价值。一个很好的起点是过滤掉信息以显示关键指标,这是否意味着减少信息或建立监控策略。

让我们考虑一些关键指标:

错误处理

有几种方法可以处理应用程序中的监视错误:

  • 使用Raygun的崩溃报告 等工具可以轻松地显示Web应用程序中发生的任何错误。该工具允许使用交钥匙解决方案来确定应用程序中发生的错误,包括频率和确定优先级;
  • 为适当的环境使用内置度量报告。例如,如果您使用Microsoft Azure进行托管,则可以设置指标,以通过电子邮件向您发送有关服务器上可能出现的任何类型的5xx错误的信息。
  • 在您的应用程序中构建错误处理 这通常是最经济和最简单的方法,但很容易失控(同时,确保您的错误处理不会产生自己的错误)。

应用程序性能监控:内部工作

接下来,应用程序性能监视(APM)是应用程序的关键指标。APM工具提供了一种监视应用程序内部工作方式的方法。最有用的功能是确定应用程序中发生的任何瓶颈。应用程序性能管理包含两组主要指标:

  1. 应用程序最终用户所体验的性能。这包括加载时间,请求量等等;
  2. 用于应用程序的计算资源。这允许确定应用程序中的任何硬件瓶颈。

例如,假设性能正在成为您的应用程序的问题,并且用户开始经历缓慢。这些问题可能变得非常模糊,难以发现。与应用程序中发生的错误不同,性能问题更多的是滑动规模。也许它只是慢,因为互联网连接很差?也许用户只会责备自己?由于性能不是绝对的,因此用户的阈值可能会有所不同。

就像错误处理一样,有几种方法可以处理应用程序性能管理:

  • Raygun的APM As APM 这样的开箱即用的工具可以是一项非常大的工作,这是一种简单的方法,可以立即从监控中获得大量价值,而无需太多工作。
  • 手动将性能记录添加到应用程序中。这包括为查询语句添加调试语句,计算时间等。

到目前为止,我们已经指出了两个用于您的应用程序的关键指标。这有助于减少信息疲劳并仅查看最重要的信息,从而使您的Web应用程序保持完美状态。下一步是查看该信息,演示文稿可以在评估Web应用程序的状态时发挥重要作用。

演示:有效地消化信息

与指标一样重要的是,管理监控功能的另一个关键方面是接收信息。理想的交付方法是不需要大量工作来收集所需信息的方法。我有两种方式来考虑这个问题:

  1. 尽快向我提供重要信息。应用程序发生故障或严重错误之类的内容符合此条件;
  2. 获得所有应用程序状态的高级视图。我应该能够快速看到这个并获得应用程序的工作状态,如果需要,可以深入挖掘。

让我们来看看以下每一个:

#1:关键信息警报

正确消化监控信息的第一个方面是收到紧急情况的警报。与涉及优先权的所有事项一样,区分紧急问题和非紧急问题也很重要。信息过载在这里成为一种风险 – 如果您开始收到数百封有关系统错误的电子邮件,那么下一个合乎逻辑的步骤就是过滤掉这些电子邮件。这使你回到以前的状态,没有良好的监控。

有一种简单的方法可以实现有效的警报:

  • 需要立即关注的关键问题是什么?停机时间,安全问题或性能下降超过SLA可以成为优秀候选人;
  • 警报的最佳方式是什么?如果您的团队正在使用Slack,获取Slack通知可能是立即与您联系的最佳方式。也许短信息?电子邮件也是一种选择,尽管将这些警报与其他电子邮件混乱区分开来可能很困难。

重新审视前面提到的Raygun产品,有一系列集成可以使警报方法易于实现。无论您认为哪种方法最适合接收警报,Raygun都应该能够覆盖它。

#2:仪表板

最后,让我们看一下在管理监控功能时消化数据的最后一个方面。仪表板提供了在任何给定时间查看应用程序状态的视觉效果。

让我们来看看Raygun为其Crash Reporting应用程序提供的仪表板:

快速浏览一下,我可以看到如下数据:

  • 当前在应用程序上的实时用户数;
  • 平均加载时间;
  • 最近崩溃的数量。

所有这些都以易于呈现的方式提供了关于应用程序性能的硬数据。如果由于开发工作而提高性能,您将能够以有意义的方式呈现它。

纠缠您的监控能力

现在您已阅读本指南,您应该配备监控的关键信息和接收所述信息的最佳方式。您是否淹没了无法弄清楚如何有效使用的指标?考虑过滤掉您的指标,只使用上面探讨的指标,看看它是否有帮助。

https://thenewstack.io/monitoring-metrics-you-cant-afford-to-ignore/

人永远不够用——在复旦大学分享SRE团队组织和管理

从10月底到12月初, 数人云与复旦大学合作开授了面向复旦大学软件工程学院软件工程硕士的《信息系统工程概论(SRE:大规模应用运维实践)》系列选修课程,今天小数为大家带来此次选修课上有关SRE团队建设的精彩分享。

源于Google的SRE有助于解决传统运维模式上的问题,SRE是在运维模式上的全新探索,也是DevOps思想在运维方面的真正实践。SRE代表了一套先进的、完整的运维体系,作为Google最早提出,又经由Google发展完善的一个崭新概念,SRE已成为一个涵盖运维理念、思路、组织架构、和具体实践的完整体系。

SRE团队的建设和管理是SRE体系中重要的部分,今天我们来介绍一下SRE团队组织和管理,其中包括SRE工程师的特点,SRE的团队组织和工作原则,SRE的内部沟通机制,SRE的新人培训,SRE团队学习演练和总结。

SRE是这样一种人

SRE(Site Reliability Engineer)即站点可靠性工程师,是一种和传统系统管理员以及普通软件工程师有所区别的新型职业类型。从这张表里我们可以看到这三类人群从工作内容、关注点、技能特长和思维特征都不尽相同。

关于程序员、系统管理员、SRE在关注事项上的区别我们可以用一个例子来说明。比如图上这是一个标准的三层结构网站,对于这样一个结构的网站,程序员的着眼点是如何处理前端HTTP的request和生成response,如何构建数据库表的结构,通过API来访问数据库以及如何优化SQL语句来提高查询的效率。

系统管理员则关注的是如何承载业务压力,规划容量和保证日常运维工作的顺利开展。这包括服务器和网络的配置是什么,如何配置和对接监控和收集日志,该使用哪种版本的中间件和数据库,防火墙和iptable的设置等等。

而一个SRE人员关注的是什么呢?重点是如何在系统地灵活性和可靠性之间找到一个平衡。比如Web服务器的负载均衡策略是什么;数据库的高可用该选择什么样的方案;如果数据库未来需要扩容,当前方案是否支持;是否要跨地域多中心地部署,相应的流量引导和数据同步问题如何解决,评估系统变化对于可靠性和可扩展性的影响等等。

所以,综上所述可以归纳出SRE应该是这样的人。他们关注问题发生的根本原因,更够通过现象看本质,能够将复杂的问题切分成很多部分,这就是我们常说的决策树。再针对这些拆分的部分提出假设,并进行测试。不断深入不同的分支,直到找到根本的原因。他们能够根据大量信息进行归纳和抽象,以便进行深入的调查。基于现有数据和经验进行判断,拒绝主观的臆断。他们不拘泥于现成的“最佳方案”而是根据实际情况追求各方诉求的动态平衡。不但解决眼前出现的问题,还会预见未来的风险和扩展可能性,从而设计出有长远目标的实施方案。最后他们不默守陈规,勇于拥抱变化,不断打破旧的经验,重复造轮。

SRE的团队组织和工作原则

下面我们来介绍一下Google的团队组织和工作原则。Google在团队组建的时候秉承的是多样化原则。团队组织成员如果过于专业化虽然能够提高成熟度,但是只有多样化才能不断解决新的问题。Google SRE团队中有着包括“技术负责人”(TL)、“SRE经理”(SRM)和“项目经理”(PM/TPM/PGM)等多种角色。

很多时候组织内部是一个动态的环境,各种角色之间可以动态地协商切换责任。一般来说,越动态的团队成员的个人能力越强,每个人都要能写代码,每个人都要具备通用的工程能力。但是动态的团队不得不面临在沟通上需要花费更多时间的问题,因此这就要求团队持续进行沟通用以平衡多样化带来的弊端。

虽然团队的角色是多样化的,但是每一项工作内容要求专业化,明确区分系统性和值班化的工作,每个阶段都必须要有一个单一的目标,确保专注做好每件事情。

SRE的内部沟通机制

Google SRE一般是通过生产会议(production meeting)来进行内部的有效沟通。会议组织者一般由相关的SRE进行轮值,项目经理、所有SRE、开发团队代表、商务等任何和项目相关的成员都会被邀请参加会议。一般这个会议一周一次,一次一个小时左右。会议的议程包括变更预告、SLO review、故障的事后总结、警报紧急评估等相关议题。

SRE的新人培训

如何培养一个合格的SRE,Google也积累了一些内容和方法。这张图内包含了SRE团队可以采用的几个培训新员工的最佳实践,同时保证老员工不会落伍。从下面描述的很多个工具中,我们可以从中选择最适合团队的几个来使用。

这张图中包含两个轴 :

  • X 轴代表了工作类型的范围,从抽象的,一直到具体的工作;
  • Y 轴代表了时间,从上至下,新加入的SRE通常对系统和服务知识了解很少。

阅读之前故障的事后总结对他们很有帮助。新的SRE也可以试图从基本元素出发反向工程整个系统,因为他们本来对系统也没有任何了解。当学员对系统有一定程度的了解,并且已经进行了一些实际操作时,SRE就可以参与见习on-call值班了,同时可以修订文档中不完善或者过时的部分。

阅读上述图表的一些建议 :

  • 正式参加on-call值班是SRE新员工的一个重要里程碑,在这之后,学习过程将基本靠自己主导,是未定义的——所以SRE参与on-call值班之后的培训计划都是用虚线标注的;
  • 三角形的“项目工作”意味着新项目刚开始都很小,随着时间推移复杂程度逐渐增大,所需投入也在增加,很有可能在参与on-call值班之后还会继续;
  • 这里的某些活动是抽象性的,还有些是被动性的。其他的一些活动,则是非常具体和非常具有主动性的,还有一些活动则是混合型的,这样的安排是为了满足不同学习方式的人,让他们都能找到合适自己的活动;
  • 为了使培训效果最优,培训课程应该节奏合理:有些可以立即开始,有些则应该在SRE正式参见on-call之前开始,而其他的则应该是持续性的,同时要求SRE老员工也参与的,在SRE正式参加on-call之前,应该处于持续不断的学习过程中。

SRE的团队学习演练

故障处理分角色演习

当面对一个经验各异、能力各异的SRE团队时,如何能够将所有人紧密结合在一起启发他们互相学习是一个挑战。同时,如何将SRE文化——不断解决问题的文化——传授给新员工,同时保证老员工始终能跟上不断变化的环境和服务发展也是一个挑战。Google的SRE团队通过一个老传统——“故障处理分角色演习”来解决这些问题。这个活动同时也被称为“不幸之轮”(Wheel of misfortune)或者“走木板”(Walk the plank)等。这个活动能很好地帮助全体成员每周共同学习并且富有趣味。具体过程很简单,和桌上RPG游戏类似:“主持人”(GM)选择两个团队成员成为主on-call和副on-call;

这些SRE与GM同时坐在房间的最前面。主持人宣布某个警报发生了,这个on-call团队就需要进行调查和现场处理该报警。

GM事先准备一个故障场景,这个场景可能是某个以前发生过的故障,新成员可能没有经历过,老成员可能已经忘记了。或者该场景是某个新功能或者马上上线的功能的假想故障场景,这样参与的所有人都不知道如何处理。

在接下来的30~60分钟内,主on-call和副on-call要试着寻找问题的根源所在。GM会随着问题的展开而提供更多的信息,例如可能会告知大家某个监控图表的走势等。如果该问题需要向其他团队寻求帮助,GM会假扮成其他团队成员回答问题。

当灾难演习RPG运转成功时,每个人都会从中学到一点东西:可能是一个新工具、新技巧,或者解决问题的另外一个角度,或者(对新员工来说)对成功解决某个问题的认可。也许这项练习可以鼓励团队成员面对下周的挑战,甚至成为接下来某一周的GM。

总结

我们已经讲过构建一个合理的错误预算是非常重要的,极端的可靠性会带来成本的大幅提升,这也包括SRE团队的人力成本。因此对SLO要有一个量化的评估,以确保和人力水平相匹配。要从根源上解决问题就是要减少琐事,将重复性工作自动化,消除运维负载,否则人永远不够用。

http://blog.shurenyun.com/shurenyun-sre-203/

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(下)

上一期孙宇聪老师关于SRE基本概念和核心原理的线上分享一经推出就引起了小伙伴们的热烈关注,看来大家对SRE的相关内容很感兴趣呀。

今天小数继续为大家带来孙老师的第二次线上分享内容,探讨SRE的一些最佳实践和成功标准,希望大家阅读愉快并持续关注我们后续的SRE内容:)

接下来聊一聊SRE的一些最佳实践,我认为Google做得比较好的几点。

SRE的最佳实践

建设平台化服务体系

首先, Google现在是一个六万人的公司,涉及到的产品线可能一百多个,各个部门之间差距很大,而且Google全球几百个数据中心,有很多机器,它如何管理?如果按照国内公司的方式去管理早就累死了。因为国内很多运维部门从上到下什么都管,从买机器开始,一直到最上面安装服务器、调试,配网络,所以业务线、运维部门经常好几千人。Google做得比较好的一点就是它把一个东西横向切分,因为它很早之前就意识到很多部门或者很多人之间有共性?像现在国内有的公司也开始讲的,运维部门要输出能力,公司内部也要服务化,因为只有服务化才能让每个团队更加专业化。

所以回到Google这个平台上,我认为它实际上是不停的在切分,就是横向切分。首先最底下是所谓的资源供给层,就是相当于把数据中心这件事情真的当成了一个资源,可以服于用户。就是用户需要什么样的机器,配置架构怎么样,怎么设计数据中心,这些东西它都帮用户做好。有一个专门的团队去做这件事情,这个团队也有自己的研发,也有自己的运维,也有自己的operation、PM,什么都有。

往上是技术架构,技术架构是大家经常听说的Borg系统等,让一些比较通用的技术或者通用的架构都能形成平台式的东西。

再往上才是产品线,每一层实际上都有自己的SRE部门、运维部门,都是一个项目。所以把这个平台搭起来之后,上层的人可以越来越少关心底下的细节问题,一定程度的减少了他很多精力、减少了很多官僚主义上的问题。需要计算资源的时候就给资源,不是还要先去审批又买机器,什么样的机器,什么样的配置都不一样,所以整个公司是一个非常同质化的公司,很多业务底下共享的东西很多。工作在越底层的人如果能服务的人越多,就会产生一个所谓的放大效应。可能大公司都是这样的,它有平台化效应,底下的人可以搞出一个世界最好的数据中心,可以同时服务几十个产品线的业务;搞出一个更好的数据库,所有人都可以用,这是Google做得比较好的一点。

容量规划和容量管理

然后大家会发现在做一个业务层运维的时候,可以关注更高级的东西,不是关心买什么样机器,而是更多关心到底需要多少容量,这些容量应该在什么地方。在YouTube我们经常在办公室摆一个世界地图,大家经常会讨论这里有一个数据中心,那里有一个数据中心,然后讨论在这边放多少容量,在那边放多少容量,它们之间如何灾备,我们可以考虑这些更高级的、更抽象的东西。这样的好处是可以真正的做到容灾,就是所谓的N+M。就是如果平时需要的峰值流量是N,M是作为灾备流量或者是这个冗余流量。N和M到底是什么?很多公司连自己的N都不知道,从来没有说过我们到底要处理多少流量,有些领导说我们“双11”想来多大量的就来多大量,这怎么能搞好?

这个问题是运维部门独特的功能或者独特的角色,要负责将把这个东西确定下来,我们到底要承担多大的流量,要有多少冗余。接下来就是验证这件事情,到底有没有这样的能力,能不能处理这么大的流量或者这么大的需求? Google有一个内部指标就是130%,比如可以处理1秒交易量是一百万,实际上集群的峰都是按照一百万的130%来处理。130%是负载均衡或者是一些外界波动导致的,它实际上是不平均的。我们可以说它是一百万条交易的负荷,但实际上不可能说一百万零一条这个系统就崩溃了。可以留一下窗口,留一些冗余量来处理一些操作中的未知性,还有一些特殊意外情况,所以130%是一个我们常用的指标。

在Google里面已经很少提灾备这件事情,就是对我们来说我们没有灾备容量,都是平均负载均衡的。可能有一些冗余,比如一个系统只能一千台机器,这一千台机器并不是说我有十台是不接受业务处理的,而是我们所有机器都是接受业务处理,只不过他们处理能力可能没有把所有的资源都用完。这也是Google有很多经验教训,如果一个东西老是不用的话,它就是坏的,你平时再怎么演习、怎么用,一到关键时刻它就过不去、它就是有问题,所以更多的时候压根不讨论灾备的问题,所有东西永远都是在线的,这也是为什么说想把Google.com给弄坏是一件非常困难的事情,得全球几百个数据中心同时出问题,才可能会出现不可用的情况。所以Google全球业务是不可能中断的,不管出现多大的自然灾害,它这个业务都是不可能中断的。可能只有局部地区受损,只有基础设施受损的地方,它才会有一些问题,所以这就是灾备。

实战演习

另外一个更关键的一点是做实战演习。刚才也提到了,SRE以业务小组为单位,每周都会做实战演习,整个公司实际上每年也会做一次非常大的实战演习。我可以举几个例子,Google很多地方都有办公室,有一年某个办公室食堂的菜有问题,导致所有人都拉肚子进了医院。这是Google总部啊,一万人、两万人这样。于是我们就提出这样一个问题,说如果这个地方没有人来上班了,网站到底还能不能正常运行啊?我也曾经问过百度、腾讯,他们所有人都在一个大楼里,如果大楼突然断网了,公司还运转不运转?这是一个很大的问题,不管是地质灾害问题、自然灾害、人文灾害,这些虽然听起来好像比较极端,但确实能考验出一个组织的业务持续能力。实际上这是Google做得比较好的一点。刚才说的都是比较夸张的例子,是比较大范围的。一些比较小的例子,比如这个系统就是你这个小组负责,你们这个小组到底有没有单点故障,这个人是不是能休假,如果一旦出现问题是不是所有人都能去解决这个问题。我们经常互相出题去做这种测试,然后去分享一些知识。我想这更多是一种风气吧。首先你认同这个目标,目标当然就是把这个系统建设得更可靠。认同了这个目标,接下来就是不停地去考验还有哪些漏洞,并确保整个团队其他人也有同样的知识,同样的技能去解决这个问题。

其实说到Google在这一点上,也有所谓的运动式演练。每年1、2月份都会组织一次运动式演练,整个公司所有部门都要参与。在这一个星期的时间里实际上公司是不干什么正经事的,所有人都想出各种各样的方法去测试或者去提高系统的可靠性。

ONCALL的正确姿势

刚才说的这种比较大的所谓实战演习,具体到工作的时候也有几个,就是我们的轮值制度值班。国内小公司都是没有轮值制度的,所有人手机24小时开机,随时打电话,随时得解决问题,一个箭步从被窝里爬出来,赶紧上去解决问题。实际上这跟Google不一样。Google的值班方式更多的是八个人每人值一个星期,值一个星期,剩下的时间你就自己去写程序、做工程研发。但是在这一个星期里,你必须能处理生产上发生的一切问题,这才是真正值班。只有你值班,别人休假了,这才是值班,否则就不叫休假,也不叫值班。所以Google有一个非常明确的规定,Google认为一个事故的正确处理或从发生到解决到事后解决需要六个小时,它认为需要六个小时。运维人员每次值班一般都是值十二个小时的班,大概从早上五点到晚上五点或者是从早上十点到晚上十点。因为它所有的值班都是由两地互相倒的,在美国有一部分,在欧洲有一部分,我们上班的时候我们值班,他们上班的时候他们值班。Google认为其实一天最多只能发生两次事件。不管什么样的系统问题,首先要保证一定要有足够的时间去处理问题。因为如果问题发生太频繁了,就像有些互联网公司,每天一上班这手机就开始“嗡嗡”在桌子上不停的响。一旦有一会儿不响了,就开始担心说这个监控系统到底是是不是坏了。

如果处理太多了,实际上就变成什么呢?两个比较重要的因素,第一个因素是你没有办法好好处理,你处理相当于就是上去敲一个命令,没有时间去想到底这个东西为什么会出现这个问题,以后怎么避免这个问题。所以这个叫(狼来了)效应,你on call的时候已经没有时间去思考了。第二个会发生“狼来了”事件。本来可能是两次完全不一样的事故,但是你上一次处理的时候,你发现重启就行了,下一次你就条件反射,出现这个问题的之后你又去重启了,但它实际上可能是另外一个问题,可能是完全不相关的问题,你重启可能导致这问题更糟糕。所以如果你总是用这种模式处理问题的话必然会出问题,早晚这个灾难会升级。本来是一个很小的问题,结果可能变成一个很大的问题。

运维重要一点是解决线上问题。很多软件工程师做运维会钻牛角尖,这个线上系统出问题了,比如商城里不能购买了,这时候如果钻到这个程序里考虑要这么写还是那么写,实际上是不解决线上的问题。作为运维这个职业或者作为运营这个职业来说,它唯一的目标就是要保证系统的正常。有的时候需要用一些比较low的手段或者是方式。比如在项目初期机器有问题,我们就把它们都停了,然后使用一些新的服务器重新搭起来。事实上也不知道这个东西为什么坏了,就把它放在这儿,先去解决生产上的实际问题。实际上我认为这是运维最大的价值。运维部门目标就是保证业务的持续性。

事后总结

接着是做总结,写一些事后总结。Google的事后总结都是非常专业的,是非常对事不对人的,它会非常详细地列出来在什么时间出现了什么问题,谁去操作的,他执行了什么操作,这个操作到底是解决问题还是没有解决问题,如果没有解决问题的话该怎么去确保不会去执行这个操作。这是一个循环往复的过程,是一个不停锤炼的过程。把解决问题当成一个职业来对待的话,所有事情都很好办了。这回出现这个问题,解决了一遍,然后发现执行了某些地方可能是系统给出错误的信号,可能是文档有问题,把它都一一解决了。下回再执行的时候,可能换了一拨人来执行这个,也能保证不会出现问题。这就是事后总结带来的最大利益。

SLO预估

最后说说SLO。SLO是运维部门的一个关键工具。服务质量实际上是运维部门唯一负责的事情。公司要求员工达到某某指标,那员工怎么去达到这一点?第一,要先帮助制定SLO,要用事实、数据去说明白达到这个服务质量到底需要多少投入、需要多少流程改进、需要多少系统改进。第二,要确保达到这个服务质量不会影响创新速度。这要有一个平衡的取舍,要用数据去说话,一个每天只能down一分钟的系统和一个每天可以down四个小时的系统,它所能承受的更新频率是不一样的,部署的要求和方式肯定都是不一样的,所以要围绕着这个去做,要把这些理念推行到研发部门和产品部门。最后就是把可靠性当成产品的一个重要组成部分,研发也得关心可靠性,他在写代码的时候得知道这个东西一定是要可靠的。把可靠性一直推到产品设计或者是业务层次去,它才能贯彻到底层的研发、运维,才能把它做好。

SRE模型成功的标志

最后就是说到底SRE成功还是不成功,实际上就是看这两条曲线。上面这条线是部署规模,大家都知道互联网的业务都是爆发式增长,它是指数型的。如果说按照常规的那种招聘曲线,直线性的,那么永远赶不上这个规模,所以运维事务必须要把它压下来。Google经常做这种统计,到底我们业务规模扩大之后,扩大了多少工单数量,然后出现了多少事故,造成了多大问题。实际上只有统计这个事情,才能知道你到底做得好不好。当这个系统成熟到一定程度之后,SRE的运维速度是固定的,甚至是越来越少的。只有做到这一点,才相当于把运维这个事情做好,剩下的时间或者剩下的精力才能去接手更多的业务、做更多的技术研发。

我分享的东西也到此结束了,谢谢大家!

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)

http://blog.shurenyun.com/shurenyun-sre-189/

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)

SRE(Site Reliability Engineering)是最早由Google提出,又经由Google发展完善的一个崭新运维理念。如今SRE已成为一个涵盖运维理念、思路、组织架构和具体实践的完整体系。数人云推出SRE系列教程,由SRE经验丰富的技术大牛们为大家分享运维一线的独家干货,揭示SRE背后的秘密。

今天为系列教程第一期,我们邀请了前Google SRE、《SRE Google运维解密》的译者孙宇聪与大家进行了线上分享。本文为上篇,讲述了SRE的基本概念和核心原理。与孙老师本人一样风趣幽默的文章,小数希望大家阅读愉快:)

今天与大家分享的内容是关于最近我翻译的这本书,据说反响还不错,今天借这个机会聊一聊书中的内容,并与大家分享一下我回国两年多以来,Google经验在国内的一些思考和落地实践。

什么是SRE?

很多时候国内把DevOps的范围定得有点狭窄, DevOps这件事情在国外更多是整个行业内的一个趋势。DevOps是一种模式,主要是让IT相关的东西与商业结合得更紧密一些,迭代速度变得更快一些,所以它适用于各个行业。今天说的SRE,我认为也是在运维行业上的一部分。

概括来说,我认为《SRE Google运维解密》这本书是一个文集。GoogleSRE全球一千多人,这个组织在公司里相对比较小众,但又是一个比较重要的部门,整个Google所有业务线的运维环境都由SRE来负责。SRE是一个非常分散的组织,每个业务线、每个部门其实都有自己的SRE小团队。这本书里共有一百多个作者联合写成,其中也包括我以前所在的团队,我们做过的一些Project也在书中也有提到,所以它是一本文集。我与原著的三个编辑聊天时,他们说成书最大的难处就是删减内容,当时征集来的内容大概有一千多页,最后删到了五百多页。这也是这本书比较有意思的一个花絮。

回到这本书的宗旨, SRE到底是什么?SRE是Google发明的一个词语或者新定义的一个职业。以前这个运维角色,大家叫运维,美国叫Operation。现在Google把这个职位扩展为SRE,就是用软件工程师的方法和手段,招了一些软件工程师来解决运维的难题,这是SRE的官方定义。

传统运维模式的弱点

现在传统的计算机行业的运维方式,大部分都是采用系统管理员的模式。大家最熟悉的运维方式是这样:招聘一些系统管理员,他们有负责采购机器的,有负责维护数据中心的,也有专门维护数据库的等等。系统管理员模式有几个特点,他们只是把一些现成的组件组装起来,并不会自己开发和创造新的系统,比如拿了MySQL把它跑起来,或是研发部门开发出来的新代码组装成之后提供这样一个服务。这是运维部门的一个特色,负责把这个东西运行好。

举一个例子,在美国的时候我们经常自嘲,说自己是流水线上的工人。因为这个流水线实际上是别人设计出来的,总得有人去操作这个机器,而我们就是一线的操作流水线的工人。又比如,我们好像是发电站里的工作人员,又或者是飞机驾驶员。飞机驾驶员就是开别人造出来的飞机,这和运维部门的职责很像。

那么这样一个运维部门的职责包括哪些呢?首先最重要的是应急事件的处理,这是重中之重,也是最唯一的职责。其次是常规更新,现在的业务发展越来越快,每周都有新的东西上线,比如说今天要买新机器,明天要改IP地址,大家可能80%的投入都是在这些事上,这就是系统管理员或者是现在运维行业的工作模式。

但是系统管理员模式有一个最大的弊端,按照传统的组织架构模式或者是这种运维模式运行会导致这个团队持续扩张,业务越来越多,需要不停的招人去应付各种各样的事。刚开始接手生产的时候,也许一周就出一次事或者是需要更新一次。因为人的沟通能力总是有限的,招了五个人之后,这五个人之间的传达问题就形成了一个困难。当你把一个精神传达给这五个人,他们事后执行出来的结果都不一样,这就是传统模型一直想要解决的问题。但是这种模型也有好处,就是市场招聘比较容易。

Google有几个比较重要的特点,首先它的部署规模非常大。Google到今天已经十八年了,刚开始前几年公司所有的人平时写代码,周末去机房接机器。因为它扩展速度特别快,部署规模非常大。如果按照传统的系统管理员的那种模式操作,这个机柜归你,这个机柜归他,再下一个归另外一个人,那么Google招人的速度一定赶不上机器增加的速度,所以Google是被逼迫创造了这样的职位,因为没有办法安排团队做如此大规模的运维。

传统的运维模式还有一个更大的问题,它过于强调专业化。比如一个人是做网络的,他只做网络其他都不管,全公司可能只有他懂网络,因为他不停的在网络上投入时间,集中力气把这个事情做好。这样一个结果就是会发现运维部门没人能休假,一出事只有一个人能解决问题。不仅仅是网络,特殊硬件、一些第三方服务都存在这个问题。这就导致了知识没法共享,人灵活性受到限制,整个组织的灵活性也受限制。这个问题,我认为它最终形成了一个负反馈的循环,每个人之间越是互相隔离,越是没有办法提高,导致服务质量上不去。最大的问题是,招来更多的人其实也不解决问题,因为这个部署规模不断扩大,人之间的知识不能共享,所以招来的人只能运维新的设备,旧的设备还是这些人在做。

这是一个怪圈。回国之后我与很多公司的朋友都聊过这个问题。以前大家讲Oracle这样的公司存在老DBA,说老DBA都是难得一见的,深居简出,但是你有什么问题,只有他能解决,其实这在Google这个语境里这是一个比较不健康的状态。SRE的一大特点就是想请假的时候随时请假,每一个人都可以请假;当出现紧急情况的时候,当天值班的人真的可以处理他负责的这个服务所有的问题。

Google SRE的起源与特点

回到最开始,Google SRE的VP叫Ben Treynor,他是一个资深的软件开发经理。2003年他加入公司第一个任务,是组建一个7人的“生产运维小组”。很快他发现如果想把这件事情做好,也就是把搜索服务运维好的话,按照Google机器增加的速度,传统的模式绝对是不可能的。机器增加的速度,系统复杂度增加的速度远比人增加的速度要多得多。所以他组建的团队有以下三个特点,注意,这里我认为其实更多的是事后的总结。首先,他的执行方式是像组建一个研发团队一样来组建这个运维团队。他招了很多他熟悉的研发工程师,这些研发工程师从开发能力上没有任何问题,用现在流行的话就是全栈工程师,什么都会做。第二点,这些人对系统管理比较有热情,懂一些Linux内核知识、网络层的知识。第三点,最关键的是这些人鄙视重复性劳动,码农最痛恨的是什么事,就是反复做同一件事。他把这些人聚到一块,然后让他们执行以前传统公司运维人员来做的事情,很自然这些人不愿意手动干,于是就写程序干。多快好省,同时写程序还有一个好处,就是可以把一些最佳实践、方式、流程、方法都固化成代码,用这种方式去应对规模性的扩张,去应对复杂度的上升。

这些是SRE跟传统的运维模式最不同的一点,就是招的人研发为主,做的事也是以研发为主。这是当时SRE成立背后的故事,这些年来我认为他们做得最好的一点是一直在维持了一种平衡。将运维部门从传统执行部门往上提升,打破了传统的界限。就像刚才说的DevOps,很多人理解为就是让研发部门做运维的事,或者运维部门做研发的事情,但实际上DevOps在国外的定义更宽泛一点。DevOps的思想更多的是说把整个开发流程的界限打通,产品有的时候也要干一些研发的事,研发有时候把这个信息要很快的反馈给这个产品,开发和运维或者QA和运维之间的界限也打通。所以现在去搜DevOps的图片,会发现IBM这些人都在讲圈圈,说以前是产品研发都是一条线直着来,而现在都是转圈的,这就是DevOps理论。

按照这个理论来说,SRE就是DevOps的思想在开发和运维之间的一个平衡。

SRE的工作职责

这个图是我发明的,书中没有提到。书里大概有二十多章的内容是在讲SRE的各种日常工作,简单提了一下它的金字塔模型,于是我归纳总结了一下。这里是由下至上,下面的事份额比较大一点,上面的事份额比较小一点,分了三类。第一类,运维部门最重要的是应急响应这个问题,因为业务越来越大,与运营的结合越来越紧密,很多时候要处理的事情更多的是商业和运营上的事,也包括软件上的问题,这个部门最特殊或者最唯一的职责就是应急响应。之上是日常运维,保证机器能够正常更新、快速迭代。再往上是输出一些工程研发,无论是做工具,还是做高可用架构、提高可靠性,这些都是最上层的东西,只有把底下全部做好了才能说到上面。

应急响应

应急响应是运维部门在公司最独特的一点,表现为当公司出现问题时,应该找谁或者流程应该是怎样的。我回国之后见了不少初创企业,他们网站出问题了,往往是CEO先发现,CEO打电话“哎,这个到底是怎么回事啊”,然后每一个人都说“不知道啊,不是我负责呀,我得找谁谁”。不管多大一件事都得传遍整个公司,整个效率非常混乱。

我在Google待了八年时间,这样的流程也经历过,但是最近这几年Google非常重视这一点,建立了一整套应急事件处理方式。首先要有全面监控,监控这件事情是持久不断的,重中之重。SRE所有人都要非常了解整个监控系统在所有业务中的部署实施,其实这是我们平时花精力最多的地方。监控系统里面对整个系统所有方面都有监控,不光包括业务指标,也包括性能指标、效率指标。监控应该平台化、系统化,不停的往上积累,多做一些模板,同质化的系统就可以用同样的方法去做监控。

第二点是应急事务处理,应急事务处理分两部分,第一部分是演习,另外一部分是真正的处理流程。如何把它做好?实际上就是要不停的去演习、去做这个事情。像刚才举的例子,网站挂了,首先不应该CEO先发现,而应该是监控系统或者报警系统先告警,在发现之前就很应该明确这个东西应该谁排查,谁处理,这个信息应该早就发给合适的人去处理,甚至他应该早就在做了。如果发生特别大的,需要跨部门之间协作的问题,那不应该只是领导现场调配,而是整个组织每个人都明白这个流程应该是怎么样的,直接就做。Google甚至可以做到在一次事故中间两地交班,某个团队处理一半,然后我交接给另外一边团队,就下班回家了,持续不停的有人继续跟踪处理这件事情,而不会出现问题。这样一个模式是我觉得非常值得我们思考的。

处理完问题之后,要总结。之前听过的一个故事是,某公司业务出现了一个事故,大家加班加点,十几个小时没睡觉把这事搞定,然后领导过来就说了一句“大家辛苦了,回家睡觉吧”。但是,其实在这个时候我要说,领导光说这个其实恰恰是不够的。领导在这里应该问:为什么加班啊?这个事情为什么会发生啊,下次能不能不发生,大家能不能不加班,能不能不熬夜?这样才对, 能做到事后总结这个事情很难,但只有把这个做好了,才能降低以后问题发生的几率。

日常运维

日常运维做得最多的可能是变更管理。业务现在发展非常快,迭代速度、迭代周期非常快。其实这件事情能做好,能够做到无缝、安全、不停的变更管理,是运维部门能给公司做的最大贡献。

第二个,容量规划,当规模大到一定程度的时候,就需要有人来回答这个问题——到底要买多少新机器,能否保证明年的性能、效率,那谁来负责这件事呢?SRE部门提出这些方案,然后要确保这些指标、这些东西是有数据支撑的,确实能解决问题的。

工程研发

工程研发虽然做得少,但是工作很关键。SRE在工程研发上主要的工作,首先是帮产品部门确定一个SLO。SLO是一个服务指标,每一个产品都有一个服务指标。任何系统都不可能是百分之百可靠的,也没有必要做到百分之百可靠。这里得有一个目标,比如说可以每个月中断几分钟。这件事情是要产品部门考虑清楚的。比如我之前在YouTube做视频存储、视频点播的时候,要考虑每个视频到底是存一份还是存两份的问题,将这种问题放到一个非常大的部署规模里面的时候,只有产品部门能够拍板。说到底是要不要花这个预算,要不要花这么多钱去提高0.1%的可靠性或者0.01%的可靠性。

另外一点是无人化运维。大家都看过《黑客帝国》吧?一醒来发现大家都是电池,都是为机器服务的。其实把这个比喻放在运维部门非常合适。因为如果不停的开发出需要人来操作运维的系统,结果大家最后都是电池,明显是不可持续的。如果不停的产生这种需要人来操作的东西,不停的招人,最后就变成不停的运维这个东西。把整个流程自动化,建立一个能够应对复杂业务的平台,这就是工程研发上最需要的东西。

SRE模型成功的关键要素

SRE在Google有十几年的历史了。这个模型是如何成功的?我总结如下几点:

职业化

运维行业从来都说不清楚自己是干嘛的,这是不对的。很多人认为会操作Linux,或者是DBA、会配网络,就算运维了。实际上运维的范围要比这个大得多。运维应该是负责公司业务正常运转的角色,这才是真正的运维。在出问题的时候能解决问题,保障业务连续性,甚至避免问题发生,这才是运维职业的定义。

具体如何做呢?推演和演习。

推演是给你一套系统,你要分析出来它会有什么样的失败模式。我们当时经常在黑板上画系统图,大家一起讨论如果这个组件出问题了会发生什么情况,用户到底还能不能看视频了,用户购买流程还能不能走通。实际上这些过程很多时候软件开发是不考虑的,但是如何拆分、如何去保证每个环节的可靠,这才反是运维这个行业最关键的一点,所以一定要做这种推演。只有这种推演才能输出改变,让系统更可靠。

第二点是演习。我们当时每周都会进行一次小型灾难演习,例如把以前出现的问题拿出来一个,让新加入团队的人去演习,所有其他的人也都要去参加。这里主要是观察新人到底是怎么思考这个系统的,新人做出的决定到底是不是正确的。因为一个人做出的决定是不是正确的实际上取决于系统给的反馈到底是不是对的。Google认为运维复杂系统不是一个靠智商和记忆力就能解决的问题,不能依赖人一定要知道这段话或这个知识点,而是要知道一种方法,知道如何去排除问题或排查问题。运维系统应该提供足够的信息,让轮值的人能够用正确的方法去处理问题。这很像是背英语辞典和会用英语聊天的区别,你再怎么背辞典关键时刻也是要查辞典的,但是真正能运用这些信息解决问题,是比较难的。

此外,要区分责任和指责。责任和指责是两个事情,但是很多公司的运维经常分不清楚。什么叫责任,就是这个事到底谁负责。但是指责是另外一回事。例如一个员工敲错了一个命令,大家说 “都是因为他的错,给他扣工资、扣奖金,让他三天不吃饭”,但这其实并不真正解决问题。再例如,比如说一个系统设计电源插座,没有仔细考虑,很容易被人踢到,结果有人真踢到了,整个机房断电了出了很大的事故。那么从Google的理念来说这里不是人的问题,而是系统设计的问题。这里是不是应该有两套电源,是不是应该有保护?只有从系统设计问题的角度出发才能真正解决问题,而指责这个踢到插座的人,让他一个月不上班,甚至当时开除也并不能解决系统的设计问题,下回总会还有人踢到。

说一个故事,故事的内容是一个事故。某个数据中心有一排机器要断电,数据中心的人发了一个工单告诉操作员要把这个开关给关了。然后这个操作员去关,他关掉了开关,但是发现这一排机器的灯没灭,另外一排的灯却灭了——按错开关了。他检查一下发现按错了,“啪”把另外一个开关也关了,然后再把这一排机器给启动,结果由于启动时候过载导致整个数据中心都断电了,扩大了问题。如果单纯只是指责,这个人肯定完了,起码奖金没有了,能不能保证工作都不知道。但是Google 更关注的是这个东西为什么会容易出错,要么是开关颜色不对,要么是相同机器的操作方式靠得太近了,会让人产生这种错误的判断。所以你看Google的机房里都是五颜六色的,因为这样确实有用,比如热水管是红色的,制冷管是蓝色的,所以查起来很容易,区分起来很容易,尽量减少了这个问题。这个设计的思想在SRE日常工作里贯彻得非常深,每人在流程或工作的时候都要考虑到有没有被误用的可能,然后如何避免误用。

专业化

专业化体现在什么程度呢?要真正的去写代码,要能给业务系统或者给研发写的东西挑出问题,提高可靠性。

第一,减少琐事。运维中有很多虚假的工作。每天很忙,然而又不解决问题,做了很多假的工作。大家看起来好像很忙,一个屏幕上十几个窗口,各种刷屏,但完全不解决问题。更好的方式是用自动化、系统化、工具化的方式去消除这种琐事的存在。如果永远靠人工,那永远都闲不下来。

第二,回到SRE,SRE制度里有一条红线,运维的人只能把一半的时间花在运维上,另外一半的时间必须搞工程上、研发上的东西。研发可以是写工具,可以是参与系统设计,参与可靠性的提高,但是要保证运维不能只干运维。

第三点,我认为也是比较缺少的,运维部门光有责任没有决策权,所以大家都说一出事故,运维就背黑锅。怎么不背黑锅呢?说改这儿、改那儿,然后发现没有人批准改动,这是最大的问题。SRE做的最好的一点是管理层对SRE的工作方式非常认可、非常支持,他们认为服务质量是服务的一个重要指标。一旦上升到这个高度,SRE部门提出一些要求就比较容易理解,得到支持,因为他们是有事实根据的。当GoogleSRE发现生产出现问题的时候,标准的解决办法就是暂停所有更新,确保业务稳定。举个比较极端的例子,像刚才说的如果发现线上系统有问题的情况下,SRE是有权利拒绝接受业务更新的,只允许研发部门修bug,不允许加新功能。这个争议我在过去八年见过为数不多的几次,开发可以一直闹到 VP,SVP 这个级别。每一次都是听SRE的。

打通与产品团队的反馈回路

所有东西不都是百分之百稳定的,稳定性的提高要消耗成本,要增加更多的冗余,更多的容量,甚至只能花钱解决。运维部门的任务就是提供这些数据和方案。比如搞三个9、四个9,要如何达到,这在投入和系统设计上有很大区别。这个部分公司里没有其他人可以提出,必须要由运维部门提出。如果没有这个反馈回路的话,你会发现大家都很痛苦,很多时候做出的决定都是违背自然规律的。我看过很多这样的案例,上面拍脑门决定某个业务要100%稳定,完全不管下面怎么搞,由于反馈回路不存在或者这个反馈回路的信息流动不够顺畅,导致了这个东西最终实际做不好,这是SRE模型相当关键的一个地方。

http://blog.shurenyun.com/shurenyun-sre-188/

实录分享|微服务落地践行渐进,4个Q&A一窥金融微服务现状

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。

PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。

PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。

DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。

数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。

DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。

敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。

例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。

微服务落地的必要条件

微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。

对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。

容器和微服务共生

容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。

不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。

基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。

变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。

首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:

1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。

数人云微服务On PaaS 产品体系

数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。

数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。

服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。

Q&A

Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下? 
A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。

在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。

但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q&A

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别? 
A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。

但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。 Q&A

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同? 
A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。

第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q&A

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系? 
A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。

轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。

把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。

如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。