index.json

[{"categories":["翻译"],"contents":" 译者：刘晓玲\n审校：冷大鲲\n编辑：张彪\n原文（作者 Saeed Khan）：How Product Managers and Product Owners can (should) effectively work together\n发布于：2018年2月4日\n 产品负责人（Product Owner, PO）这一角色在实施敏捷（例如Scrum）的公司里存在各种挑战。如果按照Scrum字面的定义来诠释产品负责人的角色及职责，会遇到诸多实际问题。\n举例来说，Scrum定义指出PO负责产品的“投资回报ROI”和“盈亏P/L”。这是什么意思呢？PO是否需要保留一套会计账簿，如果产品不盈利，就要对此负责？就单一的商业软件而言，PO甚至如何衡量一套IT应用的盈亏呢？\n无论敏捷专家怎么说，现实上PO（老实说，这个名字很糟糕）并不能真正拥有产品。\n看看《产品负责人真的拥有产品吗？》有关此主题的更多信息。\nPO是一个角色（而不是职位），一开始就有一个简单而有用的意图：\n …成为敏捷团队“业务”需求方面的专家，并与团队紧密合作，确保他们可以制作“正确”的软件。\n 这绝对没什么问题，但确实反映了一个真实的问题。最初，像企业中业务分析师这样的人可以担任这个角色，尽管他们的想法是，他们将以比瀑布式或其他前敏捷环境中更紧密耦合的方式工作。\n 但我们要明确的是，“所有权”是一个隐喻，因为，仅从开发团队的角度来看，PO代表了应用程序并为应用程序的实际所有者代言。\n 比如，PO是构建应用程序的人员/实体/个人等的代理。\n但是当敏捷开发开始被ISV（独立软件供应商）或其他组织所接受时，特别是在产品管理已经建立的地方，挑战就出现了。\nPO（在与研发一起工作时代表业务方）的职责和产品经理（Product Manager, 本文缩写为PM）的工作范围存在重叠。不仅如此，敏捷专家们还扩展了PO的定义，即便不是全部，也基本上包括了PM的大部分职责。如果你不信，请阅读来自 Scrum.org 的摘录：\n PO最有利的形式就是表现得像一个企业家，像一个“迷你CEO”。PO是真正“拥有”产品的人。\n 听起来熟悉吗？那么应该怎么解决这个问题呢？答案很简单：\n 了解核心问题 定义一个对所有人都有明显好处的合理解决方案  敏捷之前的产品管理 在敏捷产生之前，软件产品管理（SPM）已经存在了几十年了。很难说它到底是什么时候开始的，但正式接受产品管理的早期软件公司之一是Intuit（Quicken等的制造商），它是1983年由 Scott Cook 创立的，他本人就是宝洁的前产品经理。\n 软件产品管理专注于产品成功，是全局的、跨职能的业务和技术管理角色。\n 它涉及一系列广泛的活动，包括（但不一定限于）：\n 产品战略和路线图 新产品调研与需求管理 发行计划和工程协作 上市战略与规划 跨职能准备和协调  这些（和其他）活动涉及与许多内部和外部各方和利益相关者之间的跨职能合作。这种跨职能合作的简化版本如下所示。\n那么，既然我们已经就敏捷前产品管理达成一致（我们确实同意吗？），让我们回到眼前的问题。\n了解核心问题 问题的主要部分是产品负责人本身的角色以及敏捷专家们对此的看法。\n  如前所述，PO并不拥有产品。PO可能真正拥有产品的唯一方式是，自己支付所有开发和相关工作的费用，或者拥有构建产品的业务。\n  抛开敏捷教条不谈，它描述的是一个包罗万象、涉猎广泛、富有远见，且对损益负责的PO。但这是行不通的，也没有什么业务意义。\n  把重点放在“PO”最初的目标上，也就是业务需求的专家和敏捷团队的合作者，以确保构建正确的产品。\n  如今，在敏捷开发之前，上面的第3条曾经是PM在工程中扮演的角色。因此，“PO”应当是与工程师一起工作的产品管理的一部分或子集，并对这些工作负责。举例来说，PO要专注于如上所列的 发布计划和工程协作。\n这从根本上简化了问题，最大限度地减少了重叠，并在产品管理中增加了一个受欢迎和必要的专业角色。\n因此，如果我们要更新上面的跨功能图以包含PO，它看起来会是这样的：\n一言以蔽之，产品负责人/PO在工程上与产品经理/PM密切合作。PM和PO之间确实存在一些重叠：PO不仅需要与PM密切合作，还需要经常与其他方面或者利益相关方进行沟通或合作；PM有时还需要与工程团队进行沟通或交流。\n 请记住，PO总是要扮演一个“角色”（而不是职位），可以由许多人扮演，例如业务分析师、产品经理或其他人。\n 这个图目前并不完美，但确实明晰了两个角色之间的区别。\n定义一个益于所有人的合理的解决方案 我特意使用了“合理”这个词，因为我不相信在产品管理已经存在的情况下，Scrum对PO责任上的定义是可行的（例如损益、远景、路线图等）。两者之间有太多的重叠，在没有解决任何问题的情况下，这样定义会将产品管理的可扩展性难题简单的转移到PO身上。\n设计一个角色，几乎完全集中在与工程部门合作来确保正确构建产品产品，这个想法很好。是敏捷之前的传统产品管理所扮演的专职角色。\n而这种专业角色在所有环境下都是有益的，无论敏捷与否。比如任何需要产品管理和工程之间协作的地方，都可以创建一个角色来专注于此。\n 这个专门的角色被称为技术产品经理（Technical Product Manager, TPM）。\n 就是这样。这些活动和职责以前都是产品管理的一部分，因此以后也应该是产品管理的一部分。事实上，命名为“技术产品经理/TPM”就是为了消除“所有权”的歧义，并且不与Scrum或者敏捷，或者任何未来可能的新方法关联。以下是有关他们如何合作的思考。\n组织  两个职位（PM和TPM）是同一个团队的，且密切合作 TPM可直接向PM报告，但这不是必需的  责任  PM负责产品整体的成功（如产品满足其整体业务目标） TPM负责发布的成功（如构建正确的软件并最终促进整体产品的成功）  关键产品职责  PM定义路线图、发布目标和优先需求（包括敏捷中的史诗Epics） TPM与PM合作，以了解目标/EPIC等，定义需求/故事/任务等并确定其优先级，以实现发布目标。  跨职能活动  PM与销售、市场营销、执行官、合作伙伴等多职能间合作，使整个业务保持一致 TPM主要与工程（开发、QA、文档、运营）合作，并使其与软件发布保持一致  这里不可能列出所有PM和TPM需要做的工作，但关键点如下：\n 他们属于同一个团队（如产品管理） 他们有明确定义的职责，重点不同，几乎没有重叠（消除了Scrum中PO定义的核心问题） 他们协同工作，目标一致（他们在同一个团队嘛） 他们的目标和职责不与特定的软件开发方法论绑定（为什么要这样？）  这样构造，整体肯定大于各部分之和。\n因此，如果我们要更新先前的跨功能图，它将如下所示：\nPO的“角色”由职位“TPM”来取代，不仅仅是名字的改变。这是一个明确的声明，这个角色是产品管理的一部分，并且不与“产品所有权”相关。这个人是团队的一部分，其整体的责任是产品的成功。\n好，干净，简单，通逻辑且合理。你不觉得吗？\n Saeed Khan, Transformation Labs创始人\n很多公司仍在挣扎与实现有效的PM和PO角色。本文章为如何使事情做得平顺提供了背景和指导原则。提示：忽略Scrum所说的。 #Agile #ProdMgmt #产品管理\n ","permalink":"https://devopschina.org/blog/how-product-managers-owners-can-should-effectively-work/","tags":["Agile","ProdMgmt","敏捷","产品管理"],"title":"产品经理和产品负责人如何能有效地合作"},{"categories":["翻译"],"contents":" 译者：李科伟\n审校：冷大鲲\n编辑：张彪\n原文（作者 Esther Shein）：7 secrets for getting digital transformation right\n发布于：2017年11月6日 3:00PM 太平洋时间\n  技术优先的数字化转型策略奠定了失败的根基，首先要让你的组织时刻牢记以客户为中心的目标。\n 以终为始是斯蒂芬·科维（Stephen Covey）的畅销书《高效能人士的七个习惯》中的一种习惯。放在当今的商业环境中，在着手使用新技术解决一些未良好定义的问题前，组织需要弄清楚数字化转型对他们的业务意味着什么，以及数字化转型的目标是什么。对竞争力和创新力的过度聚焦并将精力付诸技术，可能会让组织见木不见林。\n当然，技术是转型的关键驱动力。IDC估计2017年会有1.2万亿美元花费在数字化转型上，这相比2016年增长了17.8%.\n但是，来自预测型公司Altimeter的首席分析师兼未来学家Brian Solis表示：由于对数字化的真正意义缺乏足够理解，许多组织未能步入数字化转型的正轨。\nAltimeter的2017年数字化转型状况报告指出，尽管组织在创新技术上进行了投资，但由于“数字化认知浅薄”，大多数企业仍未达到消费者的新预期。该报告还发现在许多公司的文化中，“政治，自我和恐惧“是公司内部合作和团结的主要障碍，同时这也阻碍公司了为适应数字化用户而进行变革。\nSolis认为，当公司采用技术优先的方法时，他们会丢掉数字化转型的目标。 “我认为很多时候，尤其是公司和CIO，都陷入了\u0026rsquo;技术陷阱\u0026rsquo;。”他说，很简单，这意味着他们正在用新技术来建立一个旧有的遗留系统。\nSolis说：“如果我们聚焦于使用客户使用的技术或最新的应用程序，移动网站或聊天机器人，那么我们正在陷阱中越走越远。我不是说这些技术都不好，但这是一个数字化转型中的常见陷阱。”\n要了解数字化转型的正确实施方式，以下是七个秘诀。\n数字化转型是人的转型 几年前，当Shamim Mohammad成为CarMax的CIO和高级副总裁时，“我不是在关注技术的变革，而是如何变革自身……以便我们所有人都在以正确的速度前进。”\nTGen的CIO James Lowey也同意这种观点，他说，业务转型面临的最大挑战之一是使员工队伍所掌握的技能与变革所必需的最新技能保持同步。\n他说：“拥有一支始终乐于拥抱新技术的杰出团队会有所帮助……通常，常规的培训一般无法跟上技术变化的步伐。” “我相信拥有充满激情，好奇心和使命感的人是成功实现真正数字化转型的关键。”\n几年前，Pitney Bowes开始研究技术在10个领域的发展方向，包括手机，数据，分析，机器学习，APIs，SaaS, 并开始设计用户体验。技术和电子商务高级副总裁James Fairweather表示：“除了明确的技术战略，我们还意识到组织要向前迈进，还需要制定人员战略。”\n围绕10个领域，我们建立了对应的课程，要求创新组织中的1200名员工选择一门课程并承诺学习一年。Fairweather表示，他们承诺会帮助员工增长他们的技能且提升他们的个人价值定位。\n观念的转变帮助公司向前发展。 “在过去的10年中，我们进行了80笔收购，但是…让员工聚焦于某一个领域，产生了许多交叉交流，随着人们彼此了解，也产生了新的关系。主动培训的巨大好处已经显现出来。” Fairweather说。\n采取以客户为中心的策略 Altimeter的报告中指出，尽管企业将“不断发展的客户行为和偏好”作为数字化转型的主要驱动力，但只有不到一半的投资用于理解数字化客户。\nSolis说：“从外而内的策略是少数走在正确转型路上的组织的选择。” “他们正在寻找一些没有或不完善的东西来满足用户的需求，”然后将ROI和关键绩效指标（KPI）结合起来“以体现进展和成功。”\n客户体验也是他们的首要关注点。他补充到：”他们着眼于用户旅程或旅程的一部分，尤其关注移动端的用户旅程，然后关注于修复某些能够带来更大机会的事物，以便将眼前的机会与其绑定起来。“\n这就是CarMax的Mohammad在管理团队前往西海岸进行“技术之旅”之后发现的，他们拜访了几家成功的公司，了解了技术“以及关于技术可能性的艺术”，Mohammad说。\n其中有一点是，他们并不是总能满足客户的需求。他说，尽管CarMax有一个面向客户的网站，但实现一个新的功能需要花几周甚至几个月的时间，而这“因为团队的组织方式不正确”，他说，“我们并没有一个迅速响应的架构。”\n组建新的团队 CarMax知道，消费者希望在其网站上购买汽车的时候能有更好的体验。 为此，领导们将员工划分为不同的产品团队，每个产品团队都有”三个至关重要、无法协商的角色“：一个产品经理，一个首席程序员/工程师，以及一个用户体验人员。然后补充其他的研发、质量保证、财务、运营，最终形成一个7人至9人的团队。\n领导们想尝试的一个点子是将汽车直接运送到消费者的家中。有个产品团队开发了一个移动应用，用户可以使用该应用购买汽车，然后汽车会在几周内被送到用户的车道上。团队“并没有一开始就寻求一个完美的方案；他们很快就让用户能够使用应用，然后致力于将这个应用及其功能变得更好。’Mohammad补充道。\n此后，首辆汽车已在北卡罗纳州的夏洛特市交付，这也是唯一开放该功能的城市。\n所有团队都会举行为期两周的“开放日”，以保证内部透明度并提供有关他们如何满足业务目标和客户需求的最新信息。\n在团队已建立的情况下，当前的目标是“在数小时内交付一个好的点子；看看它运行得怎么样，然后不断改进。这是一个很大的转变，’Mohammad说。\n在John Deere有类似的方式，高管们提出了建立智能互联型企业的目标，并推出了关于未来愿景的路线图。在公司的一家工厂中，一个7000平方英尺的名为Foundry的工作区被建立了起来，在那里，为了人们更好的协作，桌子都要矮一些。在那里，新的团队会从专家那儿学习一种新的敏捷方法，专家们会带着他们体验一个开发周期。\nJohn Deere的IT副总裁Ganesh Jayaram说：“我们之所以接受敏捷，是因为我们意识到它可以帮助我们建立学习型文化，因此我们正在进行迭代(sprint)，以便每两个月开发出一种产品。” “我们将项目进行了拆分，然后在两个月里进行增量开发。 然后，我们回顾并自问：“我们满足了客户的期望吗？”，而不是等待几个月或者几年去完成一个新的方案。”\nJayaram说，下一步就是将员工分为多个团队，通过一系列的工作坊告诉他们整个过程是什么样的，同时也通过这种方式来提升团队。 “这是一种非常不同的工作方式。 更进一步，我们正在尝试一种将应用、架构和业务协调在一起的工作方式。”\n公司战略的宣达是通过外部评估和内部访谈来实现的，以保证IT部门了解CEO及Jayaram在其他职能领域的同事对IT的期望。\n“过去我们一直被视为成本中心。”他说，“未来，我们将位于前沿和中心位置。 这是John Deere历史上的第一次，由我们领导企业的需求。 我们接受任命然后说，‘我们如何实现这一目标？’”\n在落地技术的同时鼓励和培养合作 在Pitney Bowes围绕技术领域设计课程时，领导们还成立了技术战略团队和全球创新圆桌会议，以促进更大的合作。 Fairweather说：“所有团队都在共享持续集成和持续交付方面的实践，因此对所有正在迁移到云上的应用都有好处。”\n他说，在“开拓团队”的帮助下，通过建立devops社区，公司形成了一条标准工具链以及一套标准实践。\nFairweather补充说，管理层认为面对面很重要，因此领导们发起了面对面的交流来推动不同地域团队的交互。\n在协作上的努力获得了回报。 “通过共享实践，我们在持续集成，交付和运营实践中发现了一种常见的故障模式，然后我们才能够在所有团队中进行修正和改进。” Fairweather说。\n管理层还对其基础技术战略进行了调查。 Fairweather想起了一位员工的反馈意见：“相比一颗螺丝钉，我现在是具备足够信息的贡献者。 互相学习最好的地方是带来了新的人脉。 因为我们做到了这一点，我们变成了一个在10个领域内追逐的更加团结的全球性组织。’\n坚持改变 在拥有25,000名员工的销售队伍的情况下，当工业巨头GE开始在其全球销售中应用数字化技术时，必然会遇到阻力。 在过去的20年中，大多数销售都未曾改变过他们的销售方式。\n“我们确实有反对者，但如果你想推动任何变化，不要担心他们，” GE商业和数字化线的副总裁Cate Gutowski说。\n不管怎样，Gutowski阐明了需要做的事情。 她说：“这样做时，你会积累一批早期试用者和创新者。” 她提到了《从为什么开始》书中的创新法则理论，即在事物从初始到普遍的过程中，首先要识别占比2.5%的创新者。 她说：“如果你专注于该群体，则可以建立影响力并推动任何类型的变革。”\n她认为，推动人的转型“不是为懦夫准备的，因为这实际上是要打破成规。”\nGutowski还认识到：“首先，必须坚持推动变革，还要适应变革带来的多种不适应。” 当然，从一开始就得到了GE领导团队的支持，是一种帮助。 然后，她通过“进行大量众包”让销售专家开始改变，并倾听和获取了消费者领域销售组织的需求。\n采取初创公司的心态和思维 2014年，AT\u0026amp;T的预付费运营商与新收购的Cricket Wireless合并。两家竞争性的预付费公司需要转型为一家大型国家级公司。\n同John Deere和CarMax一样，Cricket Wireless也采用了更加敏捷的开发模型，CIO兼副总裁的Darin Morrow说。 这意味着要专注于“灵活而诚信地运作，确保事情以正确的方式进行”。\n他说，随着组织规模的扩大，不同的群体开始彼此割裂，形成信息孤岛。 “创业的心态和思维有助于打破壁垒，并鼓励跨团队沟通。”\n例如，对于Cricket Wireless的数字/在线交付团队来说，更快地推出较小的功能至关重要。 他说，现场合作可以消除许多可能的沟通问题。 “我们能够及时升级并迅速做出决定。”\n驱动管理跟进 Altimeter的调查表明，只有40％的受访公司由高管指导委员会为组织转型负责。\n尽管通常情况下业务战略是由C级领导(如CEO、CFO等C字开头的领导)制定并通知其余人，但John Deere的Jayaram决定扭转这一局面。 “我选择颠覆传统的自上而下的方式”，取而代之的是召集“来自IT的不同层次结构”的40名员工，来制定公司数字化转型的IT战略。\n他说：“在向C级领导汇报前，我们一起经历了整个制定过程。’ 提供意见的一些人是公司的新人，但同时也是用户体验或敏捷开发方面的专家。\nJayaram说：“在战略最终形成的过程中，我们对整个IT部门的170位同事进行了调查，以了解战略是否有意义并方向正确。” Jayaram说。 结果是满分5分得了4.5分。\n然后，Jayaram前往最高管理层，介绍了由精益敏捷实践制定的的智能互联计划。\n他说：“我们知道人们相信这是个关于人的战略，它将完成公司转型。“然后，领导力成形，他们将会看到我们如何完成变革。\n Esther Shein, CIO 特约编辑\n ","permalink":"https://devopschina.org/blog/secrets-for-getting-digital-transformation-right/","tags":["Digital Transformation","数字化转型","IT Strategy","IT 战略","IT Leadership","IT 领导力"],"title":"成功实施数字化转型的7个秘诀"},{"categories":["翻译"],"contents":" 译者：周一行 审校：王英伟 编辑：张 彪 原文作者：MULESOFT RESEARCH, https://www.mulesoft.com/lp/reports/top-digital-transformation-trends-2021\n 在一个日益依赖数字技术的世界里，IT的作用比以往任何时候都更加关键。组织正在承受越来越大的压力，需要保持竞争力，并创造相关的体验。根据我们的连通性基准报告，预计IT项目将增长40%；82%的业务现在要求其IT团队负责提供相关的用户体验。\n为了满足这些日益增长的需求，各组织正在加速其数字化转型。这可以被定义为一种大规模的转变，即考虑如何将业务的每一部分数字化，因为业务的每一部分现在都需要技术来运行。为了推动规模和效率，IT必须重新思考其运营模式，以提供自服务的能力，并在整个企业中实现创新。\n在本报告中，我们将重点介绍CIO、IT领导者和组织在数字化转型过程中面临的一些大趋势，其中的数据从MuleSoft的专有研究和第三方处获取。\n1. 预数字化文化 各组织面临着更大的压力，要迅速按规模将服务数字化，以满足不断增长的客户需求，并创造新的收入渠道。\n客户希望通过他们的喜欢的购物方式与品牌保持一致的联系……\n……特别是通过数字化方式的时候。\n组织需要投资于新的客户服务数字化方法。 当你需要支持和联系各组织时，你的主要沟通方式是什么（过去/现在/未来）？\nIT领袖在推行数字化举措方面的压力越来越大。 你发现你被要求在你的组织中交付的项目数量增加了多少百分比？\n数字转型努力面临的最大挑战之一是一体化。\n使用API引导的方法快速合成新的数字化体验。\n Daniel Pettman, CIO，BaptistCare:\n“在BaptistCare，在我们的老年护理和家庭服务的客户中，我们一直在寻找改善和简化我们的客户服务和交付的方法。使用MuleSoft，我们通过利用API引导的连接功能，能够快速移动，更好地为我们的客户服务。我们快速而容易地集成了各种应用程序和数据，从我们的CRM系统到我们的YouChoose工具，客户可以在几分钟内在线定制他们所需的服务，提供连接的客户体验，并从几个月到几周减少项目交付时间表。”\n  Yanna Winter, CIO，Generali:\n“对我来说，视觉应用程序背后的整个集成是更重要的，因为如果我有正确的数据，我可以从相同的数据中开发10、12、20个应用程序，选择最好的应用程序，关闭其余的应用程序。如果我想能够编写和创建这些新的应用程序，每次的预算都是从零开始的。我需要能够拥有功能和数据，并编写正确的应用程序。”\n 三位行业领袖在解决整合问题，以满足数字化的需求和规模。\n- 商店增加了17倍，新增非接触式交付 Casey’s能够向600家商店推出第三方食品配送服务，而在试点项目开始时只有35家。\n- 向任何新区域的扩张速度快50% WatchBox建立了一个电子商务平台，并重用相同的API来服务五个新区域。\n- 处理时间平均24分钟 使用MuleSoft，RBC是能够挖掘遗留系统中的关键数据，并构建解决方案，以消除基于纸张的过程和繁琐的手工数据输入。\n2. 创新民主化 业务线的用户正在努力更快地开发数字用户体验。IT需要通过赋予业务自服务和更快地提供解决方案来推动文化变革。\n正在参与数字化转型的业务线（LOBS）。\n集成需求在所有业务职能中都在增加。 在IT之外，有集成需求的业务角色的前三名包括：业务分析师、数据科学家和客户支持。 除了IT，您的组织中的哪些小组或角色有集成的需求？\n组织需要使创新打破IT的四面墙。 “到2023年，大型企业中活跃的自由开发者的数量将至少是专业开发人员的数量的四倍。”\n企业寻求低代码开发工具来提高生产力。\n自由开发集成工具将在未来2至5年内进入主流采用。 “未来的技术服务将由实际使用这些服务的人组成和组合。” “自由开发集成工具通过非常直观、无代码的开发环境，使具有最小IT技能的专家业务用户自己处理相对简单的应用程序、数据和流程集成任务。” 数字化工作场所的成熟度曲线，2020年。\n在整个企业中提升团队技能，使创新民主化。\n Eileen Rizzo, IT高级副总裁，Ashley Stewart:\n“在Ashley Stewart，我们相信，通过在集成和API上提升员工技能，我们不仅帮助他们的职业生涯的成长，而且帮助我们的业务未来的发展。API引导的连接性是最关键的技能和概念，以学习创造连接的客户体验，并为市场带来新的创新。当我们在团队中推广Integration Trailblazers时，我们将能够加快我们的数字化转型的举措，特别是当我们推广我们的SaaS解决方案时。”\n 3. 组装式企业 极度专业化的行业细分已经创建了越来越多的应用程序，导致组织转向一个组装式企业，以变得更加敏捷。这样，数字能力可以由使用API的现有应用程序组成，而不是每次都从头构建。\n极度专业化已经创建了越来越多的应用程序。 仅在营销技术领域就有大约8000个应用程序。\n企业面临应用增长:\n- 1000多个SaaS应用程序 这可以用来管理公司内部运行的几乎每个方面。\n- 10-12个大型应用平台 企业用来管理财务、客户支持等职能。这些主要平台都被各种高度专业化的应用程序所支撑。\n企业将需要一个整合策略来驱动现有资产的价值。 52%的组织表示，通过构建可重用集成资产，为未来的项目节省时间和金钱，这样使得IT创造了最大的业务价值。\n组装式企业关键是要变得敏捷和交付创新。 在Gartner的“新兴技术的成熟度曲线”中，组装式企业被命名为企业复原力和快速大规模运行的关键技术。 “这种模块化的业务模式使组织能够从僵化的传统规划转向主动敏捷。组装式企业思维创造更多的创新、降低成本和建立更好的伙伴关系。” 新兴技术的成熟度曲线，2020年。\n公共领域的组织在组成新的能力:\n Kevin Jones, CIO，印第安纳州儿童服务部:\n印第安纳州儿童服务部目前正在利用MuleSoft的可重用集成资产来确保员工的安全，为92个县办公楼通过API管理建筑的运行。\n“在8小时内，我的团队为所有92个县建立了一个跟踪软件，以确定谁在大楼里，他们何时进入和离开，以满足社交距离的限制，以及我们需要多少洗手液或多少口罩。”\n  Simon Moorhead, CIO，铁路交付集团: 铁路交付集团与MuleSoft合作了其数字化铁路卡的项目。数字化票务项目利用了可以构建和重复使用的组件和编程实践。\n“新的、更现代格式的和管理更好的API，能够以一种我们以前无法实现的更具成本效益的方式，使我们走得更快。因为一旦我们建立了接口、连接和API，我们就知道我们不想重新构建它们，使用这样新的方法，我们通常就不需要重新构建了。”\n 4. 自动化 组织正在使用自动化来提升运行效率和改进业务流程。API是提升自动化和扩展生产力的关键。\n自动化是实现创新的头等大事……\n……并且提升效率。 麦肯锡估计自动化可使全球经济的生产率每年提高1.4%。 Salesforce发现70%的服务代理认为自动化的常规任务将允许他们专注于更高价值的工作。\n普华永道财务有效性基准报告发现，随着自动化和行为的改变，财务职能中可以减少多达40%的时间。\n各行业的公司都在尝试自动化。 按部门按规模实施自动化的组织比例。 （在试验或实施自动化的组织的百分比）\n然而，集成在挑战自动化。 60%的业务线用户承认，未能克服的挑战包括：连接IT系统、应用程序和数据，这些将阻碍自动化举措。\nAPI是驱动自动化的关键。 API已经成为最优雅的扩展受控访问定义范围的数据或功能手段，它抽象了底层系统的复杂性。每个API可以被视为一个离散组件，它表示业务流程的一部分、整个业务流程，或一组业务流程。为了进行业务活动，API代理两个系统之间的合同，以提供所请求的数据或服务。\n用数字看在自动化中使用API的好处:\n- 22分钟的住房贷款申请过程 使家庭贷款过程自动化，TIC:TOC使用API从电子表单应用程序以及21个其他系统中解锁数据。与22天的行业平均水平相比，客户现在可以在短短22分钟内获得全额住房贷款批准。\n- 2.5倍的更快的客户处理时间 TIAA从使用Anypoint平台开始其数字化转型的旅程，目的是通过API引导的连接来降低服务实现的复杂性。由于自动化，典型的客户处理时间现在大约快2.5倍。\n- 90秒的家庭保险报价 L\u0026amp;G保险采用API引导的集成方法，以自动化整个家庭保险报价过程。家庭保险顾问和客户在90秒内得到准确报价，销售机会增加了两倍。\n自动化的未来：声明式编程。\n Uri Sarid, CTO，MuleSoft:\n“由于不断的共同依赖的系统、动态数据和上升的期望，需要一种新的软件方法面对日益复杂的问题。有更多的人期望软件能自动工作，有更多的人期望我们的数字化生活和工作的自动化。在2021年，我们将看到越来越多的系统是基于意图的，并看到一个新的编程模型的建立：一个声明式的编程模型。在这个模型中，我们声明了一个意图，即一个期望的目标或结束的状态，软件系统通过在应用程序网络中的API连接，自主地设计出如何简单地做到这一点。”\n 5. API的安全性 平均每个企业有900个应用。新终端的大量增加为非法入侵创造了新的途径，需要强大的API的安全性。\n安全性是客户忠诚度的一个重要的因素。 84%的客户对拥有强大安全控制的公司的忠诚度更高。\n安全性也是一项最大的企业技术投资。 最大的技术投资。\nWeb应用攻击是大型安全漏洞的主要的原因之一。\nAPI可能是严重安全漏洞的薄弱环节。\n*如何构建有效的API安全策略，Dionisio Zumerle，Jeremy D’Hoinne，Mark O’Neill，2017年12月8日 资料来源：Gartner\nAPI的广泛使用增加了被攻击的风险。\n不安全的API的后果。\n确保数据和API安全的5个方法。\n6. 微服务 组织正在转向微服务，以迅速建立新的用户体验。将微服务部署到生产中的公司将需要某种形式的服务网格能力来扩展规模。\n微服务通过公开数据和功能，作为一种快速建立新的客户体验的技术而出现。 微服务将数据和功能作为一组松散耦合的服务的集合公开。使用微服务，组织可以快速适应不断变化的客户请求和需求，以及提供创造竞争优势的服务。价值来自汇集各种微服务来解决业务需求。取消客户化代码，以及管理所有这些不同的服务的复杂性问题，组织只能这样做才能体现微服务架构的优势。\n组织在微服务上加倍投入。\n*在危机响应中，银行和投资CIO的风险与业务优先事项不一致，Nicole Sturgill，2020年5月20日\n各行业越来越多地采用微服务。 按行业统计的应用栈或组合向微服务迁移的情况。\n快速消费品与微服务的相关数据。 联合利华正以微服务的方式支持其全球400个品牌的业务运行。\n- 使用微服务和API连接了1000个应用 联合利华将微服务和API结对，建立一个应用网络连接遗留系统，比如：SAP、电子商务应用，如：NetSuite和Google Analytics。\n- 6个月的发布时间 借助API引导的连接性，联合利华建立了一个可重用服务的网络，使得跨不同的品牌可以自服务。这个支持了一个新的电子商务功能的发布。\n- 新举措的部署速度加快了3到4倍 即使联合利华是一个有着庞大系统的130年的品牌，微服务架构允许它适应它的更敏捷的竞争对手的节奏。\n医疗与微服务 立法、市场和技术压力使得医疗组织当务之急是使用微服务以变得更加敏捷，包括医院和医疗系统、支付者和生命科学公司。\n- 重复住院率降低2周 NSW Health Pathology想要扩大从实验室到医疗设施的检测能力，以便患者能够更快得到确保质量的结果。团队重用了10个现有的API，以及一个大型的医疗微服务库，以便仅在2周时间里快速地构建和部署解决方案，即自动交付检测结果给患者。\n- 项目交付速度增加了4倍 Sutter Health采用了MuleSoft提供的一个微服务架构，开发了一系列可重用的API，以便维护团队、开发人员，以及合作伙伴能够轻松使用。在Sutter Health，以前需要18个月的项目，现在只需要不到4个月。\n微服务重要的地方，同样服务网格也是重要的\n什么是服务网格？ 服务网格是微服务部署的一个架构模式。它的主要目标是使得服务到服务的通信安全、快速和可靠。 根据Gartner*的说法，将微服务部署到生产中的公司，将需要某种形式的服务网格能力，以便扩展。 *《服务网创新洞察》，Andrew Lerner，Anne Thomas，2018年12月3日 资料来源：MuleSoft，Gartner\n在投资了微服务的企业中，服务网格的应用在上升 服务网格用于控制在kubernetes环境中的微服务之间的流量。\n服务网格仍然是一种新技术，但46%的组织正在试验或计划在未来12个月内评估或实施它。\n7. 数据鸿沟 为了跟上不断变化的客户期望，组织正在寻找更快的方法来解锁数据和获取分析结果。2021年是组织基于竞争对手和客户的数据，使自己快速发展的一年。解锁、分析和操作数据的能力将成为组织增长的基础。\n企业达不到客户的无缝的和个性化体验的期望……\n……由于企业很难解锁支持连接的体验的需要的数据。 在一般企业使用的近900个不同应用中，只有28%的应用是集成的，这阻止了客户的单一视图。\n解锁和统一数据对于连接的体验和增长至关重要\n2021年是组织基于竞争对手和客户的数据，使自己快速发展的一年.\n Lindsey Irvine, CMO，MuleSoft\n“现实情况是，如今，所有行业的大多数企业都无法为客户、合作伙伴和员工提供真正的连接体验。这是因为提供连接体验需要整个企业中的平均900个不同的系统和应用的大量数据。在这些系统中，集成和统一数据对于创建客户的单一视图，以及实现真正的数字化转型至关重要。” “这也是数字化转型计划失败的首要原因。随着系统和应用程序的数量继续成指数型增长，团队意识到他们和他们组织成功的关键，是在任何地方解锁数据，以帮助他们更快地交付价值。”\n 8. 数据分析 组织正在投资于数据分析，以提升用户体验。他们提供的数据将决定数据分析的价值。\n数据分析的增长。\n数据分析助力个性化客户体验。\n成长中的公司比不增长的公司在更积极地收集CX数据，Jessica Ekholm，2020年2月17日\n要从分析中得到价值，需要可访问的高质量的数据:\n- 46%的市场专业人士表示个性化的提升来自访问更实时的数据。 数据来源：Vendale\n- 平均一千五百万的年度损失被认为需要由不好的数据质量负责。 数据来源：Gartner*\n- 高度数字驱动的公司比不太依赖数据的公司有大约3倍的几率在决策上有明显提升。 数据来源：PwC\n- 大约3%的高度数字驱动的公司比不太依赖数据的公司会报告在决策上有明显提升。 数据来源：Harvard Business Review\n*如何创建改进数据质量的商业案例，Ted Friedman，Saul Judah，2018年4月23日\n组织如何利用分析获得连接的体验。\n- 重复住院率降低31% 德克萨斯儿童医院开发了一个预测模型，它使用的信息是关于预测发展为严重的糖尿病并发症的风险的影响病人的因素。医疗机构能够识别高风险的病人，以便密切监控。 资料来源：Salesforce\n- 每年节省2087项目人时 Sutter Health正在试运行一个出院系统，它利用预测分析识别高风险的病人，并规划特别的出院流程，目标是降低重复住院的风险。 资料来源：MuleSoft\n为你的数字化转型战略加油: 1、在本书中发现，为什么在今天的环境中，在整个组织中使创新成为可能，以之增加业务敏捷性是至关重要的。 2、阅读我们的白皮书来了解为什么API安全对于数字业务来说是至关重要的，因为经济加倍重视运行连续性、速度和敏捷性，以及如何保持API的安全。 3、微服务的最佳实践如何可以帮助您的组织快速变更和轻松创新。 4、在我们的白皮书中，学习如何使用服务网格和API管理，以集中管理、规模化、安全，并发现在任一架构中的服务。 5、看这个演示的网络会议学习如何轻松使用MuleSoft和Tableau建立基于数据的洞察力。  关于MuleSoft MuleSoft，一家Salesforce旗下的公司 MuleSoft是世界上第一大集成和API平台，它使连接来自任何系统的数据变得更容易，无论它位于何处，从而更快地创建连接的体验。跨行业的数千个组织依靠MuleSoft在规模上实现速度、敏捷性和创新。欲了解更多信息，请访问mulesoft.com。 MuleSoft是Salesforce旗下的公司MuleSoft LLC的注册商标。所有其他注册商标都是各自所有者的注册商标。\n ","permalink":"https://devopschina.org/blog/top-8-trends-shaping-digital-transformation-in-2021/","tags":["数字化转型","调查","数字化转型","调查","数字化转型"],"title":"2021年塑造数字化转型的8大趋势"},{"categories":["社区"],"contents":"DevOps 流水线比赛 Pipeline Craft 是什么比赛？ ‘Pipeline’ 是 DevOps 的常用术语，多翻译为“流水线”，或者“管道”。‘Craft’是手工技艺，或者手艺的意思。在绝大大多数的社区活动中，口头的交流和讨论是主要的方式，当大家交流到了技术实现的深度时，也实在是无法解决“show me the code”的需求。而流水线是 DevOps 落地的一项基础设施过程工作，Pipeline as Code 也是大多数 CI/CD 工具广泛支持的功能，那么社区为什么不做一次流水线代码的较量呢？因此，‘盛夏DEVOPS流水线大比拼’、‘多说无益，“码”上较量！’、‘要么赢取冠军，要么持续加班!’等活动宣传口号呼之欲出。这就是本次比赛最初的想法和概念设计。CI/CD 是 DevOps 实战的基础，不同的团队的实践方式各不相同，Pipeline 打造的工艺也都不尽相同。参赛者选取最熟悉的开源软件和 SaaS 服务，注重展示流水线完整性的同时，在至少某个阶段上进行展示深度。\n比赛过程回顾 本次赛事的概要信息如下。\n 活动名称：中国 DevOps 社区流水线大赛 活动时间：从 8 月 18 日到 10 月 18 日 活动官网：https://pipeline.devopsmeetup.com/ 类型：线上活动，项目代码比赛 参赛说明文档：https://docs.qq.com/slide/DUG5iamZEZWFWYlZZ  本次近百人报名的线上代码比赛活动经历了三个阶段：\n 第一步-报名参与； 第二步-打磨作品； 第三步-演示和评分颁奖。  回顾整个活动的过程，在赞助商云服务资源发放之后，参赛者们都陆续进入了作品打磨，微信群里的交流明显变得热闹起来，时间大概在十一前后，比赛进入了第一个小高潮。在最后的提交项目作品的过程中，参赛者们开始上线演示的那两周里，大家相互学习和请教的氛围逐渐到达了顶点，社区 B 站直播了所有线上演示；所有社区小伙伴不仅为参赛演示者的作品点赞，更赞赏他们的分享交流精神。大家不但赞叹工艺复杂全面的演示项目，还注重体会不同演示者关于常规流水线功能的独到见解；实现某个相同的流水线功能点背后的原因和动机是不尽相同的。\n至此，这次历时 3 个月的比赛终于胜利闭幕了，所有获奖的小伙伴们正在陆续收到奖品和获奖证书。\n再次感谢本次比赛活动的所有赞助商。\n参赛感言 参赛者们对本次中国 DevOps 社区流水线大赛整体的感言如下：\n 王翱（代表百姓网团队）：非常荣幸参加这次中国DevOps社区所举办的流水线比赛，让我们有机会和社区内的同行进行了一次零距离的交流和学习。我们团队根据目前生产实践的经验，跟大家分享了一条可以落地的流水线，同时也看到大家使用了不同的工具链去解决流水线上的问题，也带给我们更多的视角去看待问题。最后感谢中国DevOps社区的各位评审给予我们流水线的高度评价。\n  代江：感谢中国DevOps社区组织的这次活动，非常有意义，提供了各种环境产品，让我们能在此空间上尽情发挥，从无到有打造出一个属于自己的产品流水线。感谢鼓励，有所收获，但还很简陋，后面继续跟各位大佬学习。\n  覃光辉：用工作之外的时间去重新思考和实现工作之内的内容，是不错的沉淀方式。感谢中国DevOps社区举办的这次活动，让我们有机会与同行互相切磋，学习，非常棒的体验！\n  付彪：非常感谢社区提供的本次参赛机会；本次大赛不仅锤炼了自己的综合实力，还见识到其他小伙伴的DevOps流水线落地方案，也提高了我们对于DevOps实践的认知；最后祝贺 中国DevOps社区 越办越好 ！\n  刘伟：感谢组织方，协调各种资源，大家都很优秀，希望这个行业能长久健康发展\n  左国才：感谢中国DevOps社区，首先祝贺本次Pipeline交付流水线大赛圆满完成，从协调资源到代码演示，准备文案，准备会议，准备评审，准备颁奖，无时无刻都显示着你们的专业与热心。再次，感谢中国DevOps社区背后默默付出的工作者，你们是最可爱的人，为你们喝彩， 中国DevOps社区加油！\n  哄哄：感谢中国DevOps社区提供的这次交流机会，让我在分享自己一点经验的同时，也从社区同行小伙伴哪里收获不少。和技术大会相比，我觉得这种形式挺新颖，也很有意义！感谢中国DevOps社区！！！\n  葛新建：感谢组织方提供的平台，让我们有机会能与各路高手切磋。\n  尹恒岳：感谢这次大赛给了我能够把工作上的一些想法和方法进行实践和分享。\n  任传雷：工作比较忙，作品比较简陋，下次尽量做的更好，奖品很不错。\n  余为国：能和行业内的大佬们一起交流学习，收获很多。\n 对赞助商产品的反馈 感谢 AWS 对本次活动赞助的云资源，为所有参赛者提供了 AWS 中国宁夏区的访问权限，提供了充足的资源用于搭建整个流水线演示环境。下面是大家对 AWS 使用体验的反馈。\n 目前团队测试和生产使用的都是阿里云，使用aws上手会稍微别扭一些，需要一定的适应。后期使用非常流畅 第一次使用AWS的云服务，根据指引，创建服务器还是比较容易。安装相应环境软件和在普通机器上差不多。开放端口这块，基础知识储备不够，花了些时间。后面还要继续学习。 Aws的服务简单易用，提供完备的API和自动化能力，行业老大的地位真滴不一样。 感谢AWS 慷慨地提供云计算资源，本次我体验了AWS 的EC2，EKS 等功能，网络带宽速率和稳定性都很好，EKS 部署省去繁琐的创建k8s的过程，解放和运维和开发，能让大家更好专注于业务本省，能更好的快速交付应用。 第一次使用 AWS，深深感受到了 EKS 的傻瓜式使用体验，创建好之后后面几乎没有在 EKS 上花时间，给其他任务节省出不少时间！ 感谢aws提供的服务器，一直在用aws产品，会永远支持。 我使用过很多云服务AWS、GCP、Azure、AliCloud，目前的体验来说AWS是第一的，精细的IAM权限控制，EKS的完善性，是可以在生产上使用的Kubernetes环境。 几年没用了，体验还是很不错。  JFrog 为本次大赛搭建了测试环境，部署了企业版产品供所有参赛者使用。JFrog 的技术专家为本次的参赛者进行了线上产品讲解和答疑。下面是大家对 JFrog 的部分使用反馈。\n 操作手册比较清晰，Gitlab对接Jfrog的网络不太稳定 我们公司用的就是杰蛙的产品，体验也非常好。 JFrog 支持多种制品管理，支持分级授权，能很好的在团队中使用，在DevOps中是一把利器。 (1) JFrog 的 Jenkins Plugin 无法自动生成 Pipeline，对插件的使用很不友好，示例代码有很多种配置方式，对初次接触者来说可能要花不少时间在调试上。(2) 功能很全，整体使用体验不错 感谢JFrog提供的服务，虽然不太熟悉，以后有机会会慢慢了解的。  Elastic Cloud 是一种云服务，Elastic 为本次的参赛者提供了超长的 45 天全功能试用账号，Elastic的社区技术布道师为本次的参赛者进行了线上 ELK 和 APM 产品讲解和答疑。\n 实际体验非常好，企业版比开源版本管理更加方便，同时看到了新版本的Trace信息 很遗憾本次未使用，后面会学习相关知识进行尝试。 Elastic Cloud 创建集群快速方便，集成了APM，Kibana，能很好地和AWS云 结合起来，在日志分析和性能分析中能更好的助力DevOps的快速落地。 之前只使用过 ELK 收集应用日志，原来还有 APM 和监控，见识了！ 感谢Elastic提供的服务，一直在用Elastic公司的产品。 好用，使用方便。  参赛作品展示 本次比赛组工作小组成员来自社区的志愿者，他们是：大平、刘扬清、龚震天、宸星、刘征、墨香。工作小组严谨的设计了参数作品的打分规则和标准。我们在社区中邀请到了 4 位专家评委，他们是：范钢（独立咨询顾问）、Rick Jenkins（中文社区发起人）、李伟光 和 万金。评委们从 10 个单项对每个参赛作品打分，每个单项满分 10 分，对于上线演示的参赛项目，还可以获取最高 20 分的演示分，每个项目总计满分 120 分。\n获奖者名单 经过评委和社区比赛组委会一周的打分和评定工作，一下是获奖者名单。\n 一等奖 ：百姓网团队 - 王翱，李如磊，高榕，王东兴，虞伟 二等奖 ：左国才、哄哄、葛新建 三等奖 ：代江、覃光辉、付彪（壹品仓）、刘伟、尹恒岳（funplus）、任传雷、余为国、厚德载物  本次比赛活动的组委会在此感谢大家的参与和分享精神，相信在你们的带领下，下次一定会吸引更多的参数选手。\n比赛活动的最重要的特性就是“Show me the code”；这个基调既符合程序员的调性，又符合社区的 ‘少说多做’ 风格的分享。我们尊重每一份可以工作的代码，感谢和佩服线上演示参赛者的分享精神。下面是本次作品提交者的代码库清单。\n 覃光辉\thttps://gitlab.com/tobyqin/pipeline2020 厚德载物\thttps://github.com/hbstarjason/pipeline-craft 代江\thttps://gitlab.com/jd83/DevOpsChinaStudy2020/ 王翱，李如磊，高榕，王东兴，虞伟\thttps://gitlab.com/baixingwang/devops-user-service 尹恒岳\t共享库： https://github.com/yehecarry/devops-demo.git 项目地址：https://gitlab.com/yinhengyue/demo.git 哄哄\thttps://gitlab.com/goooogs/jenkins-pipeline.git https://gitlab.com/goooogs/spring-boot-example.git 余为国，刘伟\thttp://gitlab.com/louiswei/eastlake 付彪\thttps://github.com/fubiao/devops2020 左国才\thttps://github.com/ZuoGuocai/DevOps2020 任传雷\thttps://gitlab.com/leavot/rocketmq-console-devopschina 葛新建\thttps://github.com/gxjluck/xxl-job-admin  部分以上参赛者还为我们带来了线上项目演示，多场精彩的演示持续了好几天，在参赛者群里引发了热烈的讨论。社区在 B 站上直播的过程中，也回答了很多线上观众的疑问；下面是所有线上演示的录播视频，排名不分前后。\n https://www.bilibili.com/video/BV1dy4y1r7A4 https://www.bilibili.com/video/BV1up4y1k7eY https://www.bilibili.com/video/BV1pV411y79L https://www.bilibili.com/video/BV1vK411A7iq https://www.bilibili.com/video/BV1KD4y197mJ https://www.bilibili.com/video/BV1wa4y1s7PZ https://www.bilibili.com/video/BV1pz4y1Z7NR  本次大赛的组委会再次感谢大家的分享精神和参与。\n评分标准 根据所有评委以及参赛者们的反馈，一下 10 个方面的评分标准还是比较全面细致，对于任何 DevOps 团队来说，这种需求标准都比较高。评分结果公布之后，还有个别参赛者在询问他们的得分情况，表示他们想知道，在那些方面还需要重点增强的。下面是本次比赛的评分标准。\n  需求管理 1）有完整的项目说明 2）采用SCRUM或kanban等方式来进行需求管理 3）每个需求有工作量评估，定期更新工作量 4）需求和代码库关联，可以关联到代码变更\n  代码管理 1）使用github或gitlab等源代码管理工具管理代码 2）使用代码分支策略，分支短平快 3）有code review 4）所有都纳入版本管理，包括参数和基础环境等\n  制品管理 1）使用统一的制品库管理构建产物 2）有清晰的存储结构，有唯一的版本号 3）通过统一的制品库地址进行构建产物分发 4）将依赖组件纳入制品库管理\n  构建方式 1）实现构建过程自动化，定义结构化构建脚本 2）实现模块级共享复用 3）实现定期自动执行构建和代码提交触发构建， 4）构建环境配置实现标准化，实现构建资源动态弹性按需分配与回收\n  持续集成 1）研发人员具备每天多次向代码主干集成的能力，可按需集成 2）任何变更（代码，配置，环境）都会触发完整的持续集成流程 3）构建问题通过自动分析精准推送相关人员处理 4）每次代码提交构建触发自动化测试和静态代码检查\n  自动化测试\n   采用接口/服务级测试对模块/服务进行覆盖全面的接口测试； 2) 采用代码级测试对核心模块的函数或类方法进行单元测试； 3) 对系统进行基本的性能测试 4）采用测试驱动开发的方式进行代码级、接口级测试    代码质量管控 1）具有代码检查功能 2）代码质量检查完全自动化，不需要手工干预 3）对代码质量检查发现的部分问题自动提出修改建议，支持可视化\n  部署流水线 1）部署和发布全部实现自动化 2）实现团队自助一键式多环境自动化部署 3）应用和配置（的部署分离）进行分离 4） 建立可视化部署流水线，覆盖整个软件交付过程 5) 每次变更都会触发完整的自动化部署流水线\n  环境管理 1）建立全面的测试与灰度环境包括：开发环境，技术测试及业务测试环境以及灰度发布环境等等 2）环境的构建可以通过容器化快速交付\n  度量可视化 1）持续收集度量数据 2）通过可视化看板聚合报告内容多维度展示实时状态支持自动生成数据趋势图和趋势分析 3）打造应用系统的可观测性，统一采集、分析、关联和展示日志、指标和 APM\n  以上打分标准从 10 个分项评价每个参赛项目。每个分项中还有若干条详细项目，这也可以作为所有 DevOps 实践者们的检查清单，在任何 DevOps 实践项目中，大家也可以用以上打分规则做为参考进行定期自查，查缺补漏持续改进。\n总结 中国 DevOps 社区再次感谢所有社区小伙伴对本次流水线比赛的关注，感谢所有参赛者的参与，感谢参赛者的线上分享；感谢赞助商 AWS、GitLab、Elastic 和 JFrog 的赞助支持。这是一次意犹未尽比赛，对于组织方和参赛者都是收获满满。希望有更多人能了解到我们所举办的 DevOps 流水线比赛 （DevOps Pipeline Craft），Pipeline as Code 的技术实现流水线工程技术工艺在社区里的顺畅分享，在社区里顺畅的分享和交流这种技能。中国 DevOps 社区在本次的赛事组织中也积累了大量经验，我们相信明年的大赛能办的更加成功。\n","permalink":"https://devopschina.org/blog/recap-2020-pipeline-craft/","tags":["比赛"],"title":"2020年首届DevOps流水线大赛总结"},{"categories":["社区"],"contents":"社区的内容创作组正在源源不断的为社区奉献着高质量的干货文章。部分精彩文章也不断被很多知名网站转载。随着下线活动的恢复，社区的各种线上和线下活动的氛围也越来越火热。如果你也想参与社区知识内容的共建，也想一起宣传社区文化和活动。那就加入我们的‘自媒体合伙人’计划吧！\n什么是‘自媒体合伙人\u0026rsquo;? 这是一个专门为自媒体个人或者团队企业开设的合作计划。凡是有意参与 DevOps 社区微信公众号文章转载的人，即可加入本计划。\n自媒体人合伙人：\n 定期转载社区微信公众号的文章和活动 进入自媒体合伙人微信群，共同交流学习 为社区微信公众号推荐自己写的干货文章，经过社区内容运营组审核后发布，随后也会发布到社区网站的博客栏目。 通过以上活动赚取社区积分，获取社区各种福利  这是一个和社区相互推荐和曝光，共同成长的计划，希望我们也可以为社区的推广模式献计献策，与社区在自媒体的方向上共同成长。\n加入方式：请扫描下面的二维码，并发送暗号 ”自媒体“ ，在拉群后，社区微信运营组的小伙伴们，会收集的大家的自媒体账号信息。\n加入者清单  DevOps 教练 （ MyDevOps ）   ","permalink":"https://devopschina.org/blog/2020-community-wechat-partners/","tags":["贡献"],"title":"首批社区自媒体合伙人名单"},{"categories":null,"contents":"2020 中国 DevOps 社区流水线大赛 活动名称： 中国 DevOps 社区夏季流水线大赛（Pipeline Craft Championship）\n活动时间： 2020 年 8 月 18 日~ 2020 年 10 月 18 日\n活动类型： 免费活动，中国 DevOps 社区流水线大赛采取线上赛形式举办活动，通过项目代码进行角逐切磋，打造浓郁的技术氛围。\n后续活动： 社区将在 DevOps 社区年会现场对获奖者进行颁奖表彰，并邀请部分获奖者参与社区年会的技术分享。\n活动流程 01 报名参与 本活动旨在参与和学习流水线设计及实操，鼓励全国各地的 DevOps 实践者们针对流水线进行切磋。 比赛交付的应用程序可以是简单的 Hello World 应用，也可以是复杂的微服务架构项目。\n02 打磨作品 以公开的代码仓库提交作品，GitLab、GitHub、Bitbucket 和码云不限。自述文件中至少包含目标应用系统简介和流水线概述，便于评委和社区小伙伴了解你的项目。流水线项目是一个公开可见的状态，不限制 CI 服务是 SaaS 或者自建。构建和交付的应用最好是可在线访问的。代码库里包含流水线关键配置的展示截图或者短视频（个人博客或者视频网站外链接）。\n03 评分颁奖 比赛周期为 60 天，社区会对在最后提交日期前的有效作品进行评分。作品提交说明文档 、参加线上作品演示环节可获得附加分。\n评分因素包括：\nDevOps 社区评委打分，赞助商打分，社区投票。\n奖品设置：社区和赞助商分别设置，一等奖 1 名，二等奖 3 名，三等奖 5 名。\n详情请访问活动官方网站 https://Pipeline.DevOpsMeetup.com\n报名请扫下面的二维码\n","permalink":"https://devopschina.org/event/2020-pipeline-craft-championship/","tags":null,"title":"2020中国DevOps社区流水线大赛"},{"categories":["翻译"],"contents":" 社区译者：吴平福 周一行 付文新\n审校：王立杰 王英伟 高俊宁 陈文峰\n原作者：GitKraken\n 摘要 虽然在过去的几十年里，许多软件方法论已经渐渐落伍，但很显然，DevOps并不是一种趋势，它正在成为软件开发和运营的标准方式。如今，企业团队正处于DevOps转型的不同阶段，努力实现更快、更安全的技术交付，以获得竞争优势。 当开发人员与IT领导协同工作，消除路障，创建一个无缝的软件开发生命周期时，对组织的生产力、绩效、可视性、协作和创新都会产生不可思议的效果。\n也就是说，向DevOps过渡并不容易，也不直接。它需要重大的改变，包括：进化员工的思维方式，引入合适的工具，以及教授新的技能。无论你的DevOps转型在哪个阶段，你的重点都应该是持续改进。从基础开始，然后确定你独特的制约因素；一旦这些制约因素不再阻碍你，就重复这个过程。\n没有合适的工具是一个相当容易消除的制约因素，也值得投资。本报告的任务是提供指导，并从已经成功实施DevOps工具的开拓者那里获得最佳的DevOps工具。我们询问了全球的开发者社区，他们依靠哪些工具来实现DevOps的成功，我们很荣幸地提交这份报告，这份报告是基于2700多条回复的结果。\n主要研究结果 当谈到工具时，有用和易用的工具是消费者所期望的，但技术专家们往往认为，由于他们的专业知识，他们可以使任何工具发挥作用。实际上，事实恰恰相反：由于构建复杂系统和管理关键业务基础设施的困难程度，好的工具更重要。\n\u0026ldquo;表现最好的⼯程师拥有易⽤⼯具的可能性是普通⼯程师的1.5倍。\u0026rdquo; - DORA \u0026amp; Google Cloud发布的2019年DevOps状况报告\n在DevOps转型过程中，开发团队被授权对工具做出自己的决定，有助于提高软件交付绩效。他们还将工具自动化并集成到工具链中，从而腾出时间用于新的开发，并驳斥了那些认为实施起来太过耗时或昂贵的说法。\n计划 项目管理和问题跟踪 主要研究结果 无论你的团队是使用Scrum、Kanban还是敏捷项目管理的混合方法，你很可能已经做了很长时间的问题跟踪。项目管理和问题跟踪是DevOps计划过程的基础，当团队合作时，这些工具可以提供有价值的透明度、问责制和计划的准确性。\n集成和自动化在这个领域越来越重要，可以减少上下文切换，并提供跨平台执行和跟踪任务的能力。高绩效的技术团队经常将Slack和GitHub等工具集成到他们的问题跟踪流程中。\n工具 JIRA - Jira是一个Atlassian工具，最初是作为Bug和问题跟踪器设计的。如今，Jira已经发展成为一个强大的工作管理工具，适用于各种用例，从需求和测试用例管理到敏捷软件开发。\nJira提供了规划和路线图工具，因此团队可以管理利益相关者、预算和功能需求。Jira集成了各种CI/CD工具，以促进整个软件开发生命周期的透明度。当需要部署的时候，实时的生产代码状态信息会在Jira问题中浮现出来。集成的功能标记工具允许团队逐步、安全地推出新功能。\n这是一个受欢迎的DevOps计划工具，因为它包括：发布和冲刺计划、CI/CD集成、问题管理、项目待办列表、功能标记、Jira服务台集成、以及其他开发者工具集成。它的可配置性很强，这对于复杂的项目管理来说是很好的，但如果你想找一个易于实施和维护的系统，它可能不是最好的选择。\nTrello - Trello是一个项目管理工具，将项目组织成看板式的板子。2017年，Trello被Atlassian收购，此后，Trello作为Jira的轻量级替代方案，在软件开发团队中获得了很大的吸引力。如果你的组织还不是已经依赖Jira，你可以考虑使用Trello。它更容易配置和管理，而且通常情况下，开发人员更愿意与之对接，而不是Jira，由于所有的自定义功能，Jira可能会变得相当复杂，有时也会变得笨重。\nTrello提供了Web和移动版本。你的项目板会告诉你正在做什么，由谁来做，以及在一个过程中处于什么位置。项目板上写满了卡片，这些卡片是你和你的团队的任务。你的团队可以对卡片进行评论和协作，每个卡片上都可以有照片、附件、截止日期等。\n要想从Trello中获得更多的收益，你可以通过Power-Ups与其他开发工具如Slack和GitHub集成。\nGlo Issue Boards - Glo Issue Boards是在GitKraken工具套件中的由Axosoft开发的产品。如果你不熟悉的话，它与Trello类似，但Glo更以开发者为中心。这个任务和问题跟踪系统允许开发团队在看板、日历、时间线或仪表板中可视化任务。\nGlo直接与GitHub集成，以减少开发团队在完成任务时的上下文切换。Glo与GitHub的问题和里程碑进行双向实时同步，因此开发人员和管理人员可以随时了解当前项目的进展情况。\n高绩效的开发人员依靠自动化来提高工作效率，而赋予自动化功能的计划/跟踪工具正是基于这个原因而变得非常强大。使用GitHub Actions很容易设置Glo卡自动化，以减少开发人员工作流中的步骤数：本质上是通过工作流实现任务的自动化进程。\n此外，将卡与拉动请求链接起来，可以进一步实现自动化。当GitHub中的拉动请求状态被更新时，Glo卡会根据你选择的映射自动推进到另一列。Glo与GitKraken Git GUI完全集成，因此开发者在GitKraken中创建GitHub的拉取请求时，可以实际链接一个Glo卡。这些自动化功能非常符合DevOps策略，可以减少上下文切换，提高效率。\nGitKraken Timelines - GitKraken Timelines是Axosoft的一个产品，它是Axosoft在GitKraken 工具套件。它旨在帮助团队以时间轴视图的形式规划和沟通项目目标和里程碑。对于高层规划来说，这是一个很好的工具，可以快速传达即将到来的最后期限或回顾进度。每个里程碑都可以有一个图片或GIF以及相关的子项目。很容易叠加多个时间轴来比较不同项目或团队之间的截止日期。时间轴可以是私有的、协作的或公开的。而且它们可以通过链接、嵌入或演示模式轻松共享。\n当你开始进行DevOps转型时，考虑创建时间轴来清楚地传达主要的里程碑，每个里程碑需要完成哪些任务，以及相关的最后期限是什么。这个规划工具可以让每个人都朝着同一个目标前进。\n代码 版本控制 主要研究结果 版本控制是一种跟踪和管理代码修改的方法；允许开发人员看到项目的完整修改历史，并在需要时返回到以前的版本或文件。全球范围内的团队正在摆脱集中式版本控制系统（VCS），如Subversion，转而迁移到Git。根据Stack Overflow的开发者调查，由于Git是一种免费的分布式VCS，利用了分支和合并功能，现在超过90%的开发者都在使用Git进行版本控制。\n托管服务 主要研究结果 为了使用Git进行项目协作，你需要一个托管服务来托管你的存储库；另外，有些企业会选择将其托管在内部服务器上，以更好地满足其安全或部署需求。在决定使用哪种托管服务时，你的企业需要考虑价格、存储容量、与现有工具的集成度等等。企业团队将其存储库托管在多个服务上的情况也不少见。\n工具 GitHub - GitHub的核心部分，是一个托管和审核数以亿计的私有、公共和开放源码仓库的平台。GitHub也是构建该产品的公司的名字，它在2018年被微软收购。在我们的DevOps报告中，GitHub不仅在托管服务中排名第一，在我们的2020年20大开发者工具报告中，GitHub排名第7位。\nGitHub正在不断扩展其产品，以配合DevOps工作流程中越来越多的流程。为了与GitHub存储库对接，许多开发者使用GitKraken Git GUI，它与GitHub.com和GitHub Enterprise无缝集成。GitHub提供了项目（Project）和问题（Issues）的基本项目管理。像Glo Issue Boards这样的工具提供了与GitHub同步的集成，可以提供更强大的计划和跟踪功能。GitHub的其他核心组件包括代码审核、安全开发，以及最近的CI/CD。\nBitbucket - Bitbucket是Atlassian的产品，首先是一个代码管理工具。为了与托管在Bitbucket上的Git repos对接，GitKraken的GUI和其他几个Git客户端与Bitbucket.org或Bitbucket Server集成，提供了一个精简的工作流程。\n遵循DevOps的方法论，Bitbucket已经将其提供的服务扩展到不仅仅是托管，还包括项目规划、协作、测试和部署服务。正如你所期望的那样，Bitbucket提供了与Jira的紧密集成，Trello也有了与Bitbucket Cloud集成的Powerup。\nGitLab -GitLab 在我们的DevOps报告中，GitLab是最常用的托管服务的第3位，也是最受欢迎的托管服务。\n#2020年Top 20开发者工具排行榜中的第14位。GitLab是最早全面拥抱DevOps的托管服务之一，此后一直致力于打造一个完整的DevOps平台。GitLab提供了管理、计划、创建、验证、打包、发布、配置、监控和安全应用的一切。为了进一步简化开发工作流程，可以利用GitKraken的GUI与GitLab.com和GitLab Self-Managed上的Git仓库进行集成。\nAzure DevOps -Azure DevOps是微软的一款产品，提供Git仓库托管、报告、需求管理、项目管理、自动构建、实验室管理、测试和发布管理功能。该产品于2018年发布，取代了Visual Studio Team Services (VSTS)等工具，并结合了许多其他工具，覆盖了整个应用生命周期，实现了DevOps功能。要扩展您的DevOps工具链并进一步简化开发，请将GitKraken Git GUI与您的Azure DevOps托管的Git仓库集成。\n源码管理客户端 主要研究结果 源代码管理（SCM）系统是帮助团队和开发人员跟踪项目历史的工具。一个Git GUI（图形用户界面）将Git中发生的事情转换成一个你的眼睛和大脑都能很容易理解的界面。\nGUIs提供了一个至关重要的清晰的视觉展现层，消除了CLI的黑匣子体验。GUIs还通过用简单的拖放操作代替记忆命令列表的需要，减少了Git的陡峭的学习曲线。在操作上，GitKraken Git GUI比CLI更快、更高效，比如以下操作任务：身份验证、克隆repo、查看提交图、查看远程URLs、查看文件差异、将更改从本地repo推送到远程、访问文件历史记录和错误、执行Pull Request和合并解决方案，以及执行一个交互式的rebase操作。\n没有Git GUI，企业很难在所有开发团队中标准化和扩展Git的使用。GitKraken Git GUI的持续增长说明了为什么GUI方法对于用Git实现成功的DevOps工作流是不可或缺的。\n工具 GitKraken Git GUI-连续四年被评为“开发者工具”的第一名，GitKraken Git GUI是由Axosoft构建的GitKraken工具套件中的旗舰产品。它允许开发人员在彩色图形中可视化Git存储库的历史，并将复杂的Git命令简化为拖放操作。通过内置的合并冲突编辑器、交互式rebase模式、内置的代码编辑器、集成工具等，GitKraken Git GUI为有经验的开发人员简化了的Git工作流，并减少了刚接触Git的人员的陡峭的学习曲线。\nGitKraken在其他客户端中脱颖而出，因为它是兼容Linux、Mac和Windows的为数不多的GUI之一，而GitHub Desktop和Sourcetree不支持Linux。它在DevOps工作流中扮演着关键的角色，它紧密地连接了各种代码工具：Git客户端、托管服务和IDE（它使用了VS Code内置的Monaco代码编辑器）。 GitKraken Git GUI集成了上一节中列出的所有顶级的Git托管服务：GitHub、GitLab、Bitbucket和Azure DevOps，以及它们的自托管服务（不包括TFS），可以从GitKraken内部实现以下所有功能：在托管帐户上创建存储库，包括.gitignore文件和license文件；自动生成一个SSH密钥对，并将其添加完成；fork存储库；将身份验证保存到配置文件中；从您的repo列表中克隆；为repo添加远程地址；使用添加的分配者、审阅者和标签创建pull requests；查看pull requests的构建状态。\nGitKraken Git GUI还通过连接计划和代码步骤，支持无缝的DevOps工作流。GitKraken Git GUI内置了Glo Issue Boards和GitKraken Timelines等规划工具。为了便于跟踪，Git GUI中的存储库可以与Glo Boards相关联。当创建一个新的GitHub pull request时，只需链接一个Glo card；这将自动更新GitHub中的pull request描述，以包含到该卡的链接。另外，GitKraken Git GUI与Glo Issue Boards、Jira、GitHub Issues和GitLab Issues的更紧密、更强大的集成版本即将推出！\nGit CLI-在Git GUI之前，程序员被迫使用命令行界面（CLI）。CLI继续被广泛使用，因为它是免费的，许多人仍然通过记忆命令来学习Git。此外，它还提供了额外的好处，即能够使用脚本自动执行某些任务。一些开发人员也不希望依赖于GUI应用程序，而是希望看到他们输入的命令的输出。\nGitHub Desktop-顾名思义，GitHub Desktop是一个GitHub工具，在微软旗下。由于GitHub.com拥有广泛的用户群，该工具已被广泛采用。对于GitHub用户来说，它是一个免费的、易于使用的工具，但是它的功能不如GitKraken Git GUI或Sourcetree那么强大。对于那些不使用GitHub作为托管服务的，或使用多个托管服务的人来说，GitLab、Bitbucket或Azure DevOps没有集成其中，这是一个相当重要的工作流的障碍。\nGitHub Desktop非常适合已经使用GitHub.com并且需要基本Git客户端功能的Windows和Mac开发人员，例如：与协作者一起分配提交；使用pull request检出分支，并查看CI状态；语法突出显示的差异；扩展的镜像差异支持。Git客户端不适用于Linux用户或团队，这些用户或团队需要一个客户端来进行：交互式rebase、提交签名、GitFlow、子模块、blame、打开多个repo、自动存储、提交模板、文件/差异视图、文件编辑等。GitHub Desktop也没有提交图，因此可视化项目历史的能力有限。\nSourcetree-Sourcetree是Atlassian产品，2010年首次向公众发布。这个Git客户端对Windows和Mac是免费的，但不支持Linux。作为市场上最早的Git GUIs之一，Sourcetree能够在开发人员中获得巨大的吸引力，特别是那些已经使用了类似Jira和Bitbucket的Atlassian产品的开发人员。\nSourcetree的功能比GitHub桌面丰富得多，与GitKraken Git GUI的功能更接近。然而，Sourcetree缺少模糊查找器、语法突出显示、自动存储、文件/差异视图、文件编辑和pull request模板。\n说到DevOps，Sourcetree提供了与GitHub、GitLab和Azure DevOps的集成，主要对手是Bitbucket。\n集成开发环境 主要研究结果 由于IDEs提供的便利性，它们越来越受到软件开发人员的欢迎。IDE是一个软件套件，它将开发人员用来编写和测试软件的许多工具整合到一个用户界面中。IDEs提供了较少上下文切换的优势，这就是为什么许多工具都朝着这个方向发展，比如：GitKraken Git GUI及其内置的代码编辑器、合并冲突工具和集成的问题跟踪功能。\n工具 VS Code-VS Code不仅是我们DevOps报告中排名第一位的IDE，而且在2020年、2019年和2018年的20个顶尖开发工具中，它还排名第二位。VS Code是一个非常流行的代码编辑器，用于在Windows、Mac和Linux上编写、构建和调试web和云应用程序。\n作为微软公司的工具，它还具有与Azure、AWS、.NET紧密集成的额外优势，以及一个庞大的插件的生态系统，允许您连接、构建和调试许多工具和技术。通过VS Code与Azure一起使用可以简化DevOps工作流，以便轻松部署和托管基于React、Angular、Vue、Node、Python等构建的站点。此外，使用VS Code的Glo Issue Boards插件，可以加快任务和问题跟踪。\nIntelliJ IDEA- IntelliJ IDEA是Jetbrains提供的Java开发IDE，它创建了一整套开发工具。虽然IntelliJ没有VS Code那么流行，但它是DevOps报告中使用最多的IDE的第二位，也是2020年的前20个最好的开发工具中的第9位。该开发工具的吸引力逐年上升，在我们的20大开发工具报告中，2019年排名第10位，2018年排名第11位。\nIntelliJ IDEA作为编程软件，提供了快速直观的体验。虽然IntelliJ是一个用于Java的IDE，但它也理解并为其他各种语言，比如：SQL、JPQL、HTML、JavaScript等，提供智能编码帮助。\n为了增强DevOps工作流，IntelliJ IDEA支持Maven、Gradle、Ant、Gant等构建工具，以帮助自动化编译、打包、运行测试、部署和其他活动。为了方便地执行单元测试，IntelliJ包含了主要测试框架的测试运行程序和覆盖工具，包括JUnit、TestNG、Spock等。此外，IntelliJ IDEA还提供了一个专用的工具窗口，允许您连接到本地运行的Docker来管理镜像、容器和Docker Compose服务。\nVisual Studio-Visual Studio是微软开发的另一个IDE，不要与Visual Studio Code（VS Code）混淆。它也很受欢迎，在我们的DevOps报告中排名第三，在2020年的前20个开发工具中排名第四。这个集成开发环境包括所有平台和语言的工具和服务。\nVisual Studio提供了一些特性来帮助处理DevOps工作流的各个部分：开发、分析、调试、测试、协作和部署。此外，作为一个微软工具，Visual Studio通过Azure的项目模板和直接部署到Azure，使Azure开发更加容易。另外，Visual Studio还有一个扩展市场，可以与其他流行的开发工具集成。\nSublime Text-Sublime Text是一个跨平台的文本编辑器，用于代码、标记和文本。这个成熟的IDE是稳定和快速的。它具有自动完成、语法突出显示和代码折叠功能。Sublime Text是DevOps报告中使用最多的第4个IDE，也是2020年前20个开发工具中使用最多的第8个IDE。\n构建 构建工具 Jenkins-Jenkins是一个开源的自动化服务器，允许组织通过自动化来加速他们的软件开发。Jenkins在整个DevOps生命周期中管理和控制软件交付过程，包括构建、测试、运维和部署。设置Jenkins以监视GitHub、Bitbucket或GitLab上的任何代码更改，并使用Maven和Gradle等工具自动进行构建。利用容器技术，如Docker和Kubernetes，启动测试，然后在生产中采取回滚或前滚等操作。\nMaven-Maven是一个构建自动化工具，主要用于Java项目，但也可以用于构建和管理用C#、Ruby、Scala和其他语言编写的项目。Maven项目由Apache软件基金会托管。\n团队可以使用Maven的项目对象模型（project object model，POM）和一组插件，来使用统一的构建系统构建项目。一旦您的团队熟悉了一个Maven项目是如何构建的，您就会知道所有Maven项目是如何构建的，从而在尝试确定许多项目时节省了时间。\nVisual Studio-Visual Studio的Windows和Mac版本有用于所有.NET语言的内置编译器工具。使用它可以立即创建构建，并在调试器中测试它们；为C++和C类项目运行多处理器构建；自定义构建系统的不同方面。您可以使用MSBuild命令行工具来自动化Ci/CD管道中的构建，或者在Windows和Linux中使用CMake工具运行C++构建。\nGradle-Gradle是一个开源的构建自动化系统，可以帮助团队更快地构建、自动化和交付更好的软件。开发人员可以使用Gradle来编写Java、C++、Python等，并在任何平台上打包部署。Gradle的插件和集成生态系统帮助团队扩展自动化。端到端地对软件的交付进行建模、集成和系统化，并使用快速构建扩展开发。Gradle提供了许多功能，从编译避免到高级缓存，再到支持持续交付。\n测试 执行测试 主要研究结果 测试框架对于成功的DevOps策略是不可或缺的，因为它们有助于为创建和设计测试用例提供高级指导。测试框架提供了实践和工具的组合，旨在帮助开发和QA团队更有效地测试。\n测试工具可以帮助企业团队提高测试速度、提高准确性、降低维护成本和降低出错风险。有了高效的DevOps工作流，开发人员可以在持续交付期间使用这些工具，来减少QA的监督。\n工具 JUnit-JUnit是一个面向Java的开源单元测试框架。JUnit对于在测试驱动环境中工作的开发人员非常有用，因为它有助于在代码的早期发现错误，从而使代码更加可靠。单元测试还迫使开发人员花更多的时间阅读代码而不是编写代码。这会产生更可读、更可靠、无错误的代码，从而在开发过程中建立信心。\nSelenium-Selenium是一套自动化web浏览器的工具。它提供了一个回放工具，用于编写功能测试，而无需学习测试脚本语言。\nSelenium WebDriver是特定语⾔言绑定的集合，用于驱动浏览器。它帮助QA团队创建健壮的、基于浏览器的回归自动化套件和测试，并可以跨许多环境扩展/分发脚本。\nSelenium IDE是一个Chrome和Firefox插件，可以简单地记录和回放与浏览器的交互。它帮助QA团队创建快速的bug复制脚本，以及用于自动化辅助的探索性测试脚本。\nSelenium Grid非常适合希望通过在多台机器上分发和运行测试来扩展规模的QA团队，同时从一个中心点管理多个环境。这使得在各种浏览器和操作系统上运行测试变得很容易。\nJest-Jest是一个JavaScript测试框架，可以与Babel、TypeScript、Node、React、Angular和Vue一起工作。Jest速度快，几乎不需要配置。它使用快照测试来跟踪大型对象；快照可以与测试一起运行，也可以嵌入代码。\nPHPUnit-PHPUnit是一个面向程序员的PHP测试框架。它是单元测试框架的xUnit架构的一个实例。许多现代PHP框架都带有PHPUnit集成，包括Laravel、Symfony和CakePHP。CMS包括Wordpress和Drupal也使用它进行测试。\n发布 配置管理 Ansible - Ansible为基础设施、应用、网络、容器、安全乃至更多其他多样性的系统提供了简单的自动化方案。Ansible通过配置对基础设施的数据信息进行直接描述，提升了文档的可读性。系统管理除了账号密码或者SSH密钥外，再也无需它物。不需要再安装代理软件，避免了自动化系统常见的“为了管理而管理代理软件”的问题。Ansible依赖于OpenSSH，而它又是最安全的远程配置管理系统之一。\nAnsible不仅在DevOps报告中位列配置管理工具第一名，而且在2019年Stack Overflow的开发者调查显示：62%的使用过Ansible的开发者都特别喜欢这个工具。\nAzure DevOps -Azure DevOps是由微软创建的一系列DevOps解决方案的集合。使用Azure云的自动化功能简化了其中的配置管理。整个系统的资源配置的统一管理增强了系统状态的可靠性，做到随时回滚配置更新，自动化处理异常修改和问题排查。\n编辑和管理PowerShell的配置，导入配置脚本，生成节点配置，这些都可以在云上完成。使用Azure配置管理来监测和自动化更新物理机和虚拟机的配置。\nChef-Chef 是一个处理物理机、虚拟机和云上主机的配置管理工具。它赋能IT流程的持续自动化，促进企业组织的高效团队协作，Chef Automate利用chef、Habitat和InSpec构建横跨内外边界的管道，标准化本地数据中心和公有云的环境和流程。\nDevOps人员利用相同的工具把配置编程代码，流程化处理申请，高效的准备环境和发布应用。\n持续集成/交付（CI/CD） 主要研究结果 持续集成是DevOps最佳实践之一，旨在一天多次合并代码到同一个共享库，然后从此库开展自动化构建和测试。CI助力于企业研发小组快速监测错误，减少合并错误，避免问题积压恶化。\n持续交付在CI之上更进一步，使得软件可以在任意时间内发布到生产环境，通常自动化推送更新到临时系统中。企业研发小组认为DevOps的CD实践保证了每次的修改都能发布，而且还降低了每次发布的风险。这让企业通过更频繁的提供价值获得竞争优势，创建更为紧密的客户反馈闭环。\n工具 Jenkins - Jenkins 是我们调研报告中排名第一的CI/CD工具；它有助于企业通过自动化加速软件开发。Jenkins通过DevOps生命周期控制和管理着整个软件的交付周期，包括：构建、测试、运维和部署。通过Jenkins来监控GitHub、Bitbucket 或者GitLab中的任何代码变化，并自动触发利用Maven或者Gradle编译的构建。利用如Docker和Kubernetes的容器技术初始化测试环境，并在生产环境中进行回滚或前滚。\nGitLab - GitLab通过自行演进，成为了一个覆盖整个DevOps周期的应用。因此GitLab CI/CD只是整个GitLab应用中的一小部分，提供从计划到部署的无缝用户体验。可以利用GitLab CI/CD在Unix、windows、macOS或者任何运行Go语言的环境，此外还支持多机器构建，以加快速度执行速度。GitLab CI/CD还支持实时日志输出、柔性pipeline和可视化pipeline、自动拓展、制品构建、支持Docker和容器注册等等。\nAzure DevOps - Azure DevOps是由微软创建的一系列DevOps解决方案的集合。开发人员利用它可以自动化从编码到上云的整个持续集成和持续交付的DevOps流程。\n通过Azure的端到端的解决方案，开发团队可以实现整个应用生命周期(计划、开发、交付和运维)内任何阶段内的DevOps实践。通过与Visual Studio和VS Code的紧密集成，开发者更容易在Azure DevOps上致力于自己的CI/CD流水线。\nTravis CI - Travis CI是由Github提供的持续集成服务，用于构建和测试上传在它上面的工程。相较于Jenkins，使用Travis CI的一大优势是更快的初始化：登录GitHub、测试工程、推送至GitHub一气呵成。如果你所在的组织利用Github开展开源项目，Travis CI是一个好选项。Travis CI还集成了广受欢迎的通讯工具，例如Slack，以保证开发团队随时了解构建状态。\n部署 部署环境 主要研究结果 持续部署是企业拥有成熟的DevOps流程后的一项进阶的DevOps实践，它比持续交付更近一步，可以自动化部署更新到生产环境中，而不是其他非生产环境。研发小组不管是部署到生产还是非生产环境，都需要一个工具来实现部署策略。\n工具 Jenkins - Jenkins 不仅仅只是一个构建工具，同时也是持续交付解决方案中被采用的最广泛的工具之一。无法计数的Jenkins插件，让其几乎能整合任意工具，包括整个持续交付流程中所有最经典的解决方案。Jenkins插件让开发人员可以通过网络部署docker镜像，部署到Kunenetes机群。使用Pipeline插件，开发人员还可以调用云服务提供商（AWS/Azure）的API通过流程即代码的方式部署任意服务。\nAzure DevOps - Azure DevOps 是一套微软提供DevOps解决方案，Azure Pipeline是其中的一个服务，它可以用于自动化构建和部署到众多的云提供商，尤其是Azure。\n如果贵公司开发了一个.NET、Java、Node、PHP或者Python的App，Azure Pipeline可以帮助您设定一套高度定制化的持续集成和持续交付的流水线。\nAWS - AWS CodeBuild 是一套掌控全局的集成服务：编译代码、运行测试、生成带部署的软件包。它还不需要服务器来部署和扩展，也不需要安装、配置和运维任何软件。\nAWS CodeBuild是 AWS Code Services家族中的一员，通过AWS Code Services可以创建、完成和自动化软件持续集成和持续交付的发布流程。你也可以只集成Code Build到已存在的CI/CD流程中去。例如: 可以利用Code Build当作已有的Jenkins的一个节点来设置分布式构建。\nGitLab - GitLab CI/CD不仅仅只能测试、构建项目，还能够部署到基础设施上。GitLab为每个环境提供完整的部署历史记录，且能够持续追踪部署状态，因此可以查询到当前服务器的部署信息。如果项目连接的是Kubernetes，也可以用它来辅助部署。\nGitLab致力于自动化发布与交付应用，缩短交付周期，加速手动流程，提高团队效率。随着无触化持续交付被引入流水线，系统自动获取信息识别做要做的事情，进而实现自动化多环境部署，不管是生产还是非生产环境，甚至实现更加高级的方式，如金丝雀发布。通过特性开关、内置审计/可追溯性、按需环境创建和GitLab的静态内容交付页面，可以实现更有信心的更快速的交付。\n运维 容器 Docker - Docker这一个工具的设计目标是使用容器来更简单的创建、部署和运行应用。Docker容器把软件和其依赖环境结合在一起设置成一个标准化单元来部署，该单元包含运行所需的一切：代码、运行时、系统工具和标准库。企业团体使用Docker容器来保证应用始终运行一致，让协作变得像分享容器镜像一样简单。\nDocker不仅仅在这篇DevOps报告中位列容器工具排行榜第一，而且在2019年Stack Overflow的开发者调查显示：Docker还是排名第三的最通用平台，35%专业开发者报告说他们在Docker平台上开发过东西，Docker还是该报告中排名第二的最受喜爱的平台。\nKubernetes - Kubernetes是一个开源的容器编排工具，旨在自动化应用部署，扩展和管理。Kubernetes起初是Google的一个项目，现在由CNCF(云原生计算基金会)维护。\nDocker 和Kubernetes并不直接竞争，Kubernetes是服务于类似Docker这样的容器平台的容器编排器。主流的云供应商都支持此功能。如果企业打算上云，Kubernetes是个非常可靠的选择。它提供了一个主流的框架来运行分布式系统。每个项目的开发到生产环境，研发小组都能够运行在一致的基础设施之上。Kubernetes可以管理扩展需求，可用性，故障迁移，部署模式等等。\n尽管Kubernetes是个健壮的工具，但它的复杂性以及在DevOps工具链中新增的非必需功能也臭名昭著。许多像AWS和Azure的云服务提供商提供的云编排能力就能够满足企业的需要。\nAWS - AWS名如其意，是AWS的提供的服务，旨在按需提供云计算平台和对应的API。如果你使用其他的AWS开发者工具来掌管代码、构建、测试和部署服务到AWS，那就应该考虑扩展DevOps工具链，并在AWS上运行容器。\n如果贵公司选择了AWS，那么就会涉及一到两个容器编排工具：Amazon的ECS或者EKS。如果对AWS的架构和API熟悉，那么使用ECS来运行容器是更好的选择。因为ECS于AWS的其他服务深度集成，如：IAM、VPC和Amazon Route 53。如果使用Kubernetes，那么EKS是个安全、可靠、可扩展的运行Kubernetes的方式。\n监控 分析/监控 Google Analytics - Google Analytics是一款强大的分析和监控工具，帮助企业团体收集、配置和分析关键数据。该工具提出的洞见可基于用户和网站、网络应用、Android和IOS下的APP交互。开发者可以利用Google Analytics的健壮API来创建综合报告和定制化配置。\nGrafana - Grafana是一款开源的分析和监测工具，支持十几种用于从源头拉取数据的本地化数据库。它极度可视化，从热力图到直方图，图表到地理图以及各种各样的仪表盘。Grafana还支持团队使用Slack之类的工具发送告警和通知。\nAzure - Azure 监测器是微软提供的用于对应用、基础设施和网络进行全局可视化监测的工具。通过Azure Monitor遥测技术实现全站监测，触发式告警和获取日志。\nAWS - AWS CloudWatch向DevOps工程师、研发人员、SRE工程师和IT经理提供监测和分析的服务。CloudWatch提供数据，研发人员采取行动：利用此工具来监测应用，反馈性能变化，优化资源，获取运维健康状况的概览。\nCloudWatch以日志形式收集监控和运维数据，度量指标，提供关于运行在AWS或者内部服务器上的资源、应用和服务的相关信息。\n即时通讯 Slack - Slack是一款基于云实例的消息平台，可以拨打视频电话，还基于话题管理频道中的聊天历史记录。它在企业内部被当作实时的邮件使用，研发人员可以获取企业范围内的关键信息和专家的支持，也可以进行项目级的回顾和协作。实时追踪多系统的性能数据以更快速的解决问题，通过衔接其他服务和平台来流线化和自动化工作流程。\nSlack集成了主流的项目管理和问题追踪工具，如Jira、GloIssue Boards和Trello，快速响应新增的bug和task，而且无需文档转换。Slack还直接集成进了GitHub、GitLab以及Bitbucket。\nMicrosoft Team - 微软的Teams是一个结合了文字聊天、视频会议、文件存储和应用集成的通讯平台。如果企业依赖于微软工具套装，那么Teams就是理想团队协作的中心。使用Teams可以实时访问、共享、编辑Word、PowerPoint和Excels文件。\n总结 引领性企业还在进行DevOps转型，以通过更安全和快速的交付他们的技术来获取竞争优势。DevOps转型会涉及众多方面，包括员工的思维定式，新技术的教学，合适工具的引进。本报告聚焦于已成功实施这些工具的2700多开拓者，总结出最好的DevOps工具。\n把报告分享给其他干系人以展示DevOps转型中工具的重要性。我们的报告明显证明了一点，高效的软件工程师和IT领导会选择有用且可用的工具以在DevOps转型中提升生产力和价值交付；同时也自动和集成新工具到他们的工具链中，释放更多的时间在开发上。这也驳斥了工具实施费时费力的观点。\n点此下载原版pdf报告文件 ","permalink":"https://devopschina.org/blog/devops-tools-report-2020/","tags":["DevOps"],"title":"2020年DevOps工具报告"},{"categories":["翻译"],"contents":" 社区译者：刘晓玲 谭峤 陈思宇\n审校：王立杰 王英伟 高俊宁 陈文峰\n原作者：暂未发现 原文地址：https://enterprisersproject.com/devops\n DevOps作为一种IT方法论和文化，至今已有10年的历史，但许多IT人士仍然感到它很新鲜并且充满挑战。这是因为DevOps的方法，工具和文化原则在不断的变化和改进。 “ DevOps是一个过程，是一种算法，” Datical的CTO Robert Reeves最近这样告诉我们，“其全部目的是随着时间而变化和发展的。”\n【您是DevOps的求职者还是招聘经理？ 获取我们的免费电子书： DevOps 终极招聘指南. 】 如何才能跟上变化并持续从DevOps从业人员那里学到最新经验？ 我们为IT领导者准备的DevOps指南，提供了持续不断的最新和最佳信息，因此您只需要在这里便可以深入探究。 让我们深入研究来自DevOps专家和顶级CIO的专家建议与分析。\n为什么DevOps在企业IT中很受欢迎? 由于某些重要原因，DevOps不断在企业IT中赢得粉丝。这种工作方法对速度，实验和协作实行奖励，这些都发生在跨职能团队中。它打破了在IT内部组织中开发和运维团队之间的传统壁垒，加快了软件发布的节奏。\n所有这些因素都适合当前的业务目标：业务转型。它可以快速更改以满足客户需求或新的竞争形势。加快步伐，使制造业公司能表现得像一个初创公司，而不必像官僚机构那样。实验与创新-这些目标是数字化转型的核心， 是目前许多CEO的首要任务。\n在过去的几年中，当公司安排小型，灵活的开发人员团队，去解决特定的业务问题并将他们从传统的组织规则中解放出来，DevOps便推动了企业的成功。这种工作方式重塑了许多行业中企业IT的工作方式（以及关键业务流程），如Vanguard，Target和Macquarie Bank等。 （有关更多信息，请参见麦格理银行的案例研究。）\n对于先锋CIO约翰•马坎特（John Marcante）而言，DevOps在他的团队共同目标中扮演着至关重要的角色：即使作为全球金融服务巨头，也要“以创业公司的速度交付业务价值”。他说，他的团队“正在拥抱DevOps原则，以便减少从代码提交到我们的版本管理系统到产品功能对客户可用的时间。”\n为了最大限度地提高速度，他的团队依赖于将敏捷云基础设施、微服务方法、自动化和新测试方法结合使用的DevOps方法。（有关其团队方法的更多详细信息，请参阅我们的相关文章，提高美国先锋 IT速度和创新的转换模型。)\n数据点：据弗雷斯特称（Forrester Research）， 2018年是企业DevOps年，50%的组织正在实施DevOps，另有27%的组织计划在未来12个月内实施DevOps。资料来源：Forrester的2017年第一季度全球DevOps基准在线调查。\nDevOps最佳实践：是什么造就了一支出色的团队? 优秀的DevOps商店具有三个特点：速度、协作和自动化（因为将日常工作自动化，可以使人们腾出更多精力，来处理更具挑战性的问题）。\n你还将看到对文化的高度关注：DevOps的工作风格——快速且跨越组织边界——要求人们成为可变的角色，并将失败作为学习经验来接受。\n当然，DevOps不仅仅是速度。 真正出色的DevOps商店将成功与业务成果联系在一起。 红帽公司（Redhat）的Matt Micene说：“ DevOps不是简单地加快速度，而是更快地交付价值。” 他经常撰写和演讲DevOps文化。 （请参阅我们的相关文章DevOps 工作：如何识别一家出色的DevOps商店.)\n是否应该有专门的“ DevOps团队”？ 这个问题在DevOps社区引起了极大的争议。 有人说是。 有些人甚至主张创建DevOps卓越中心。\n还有人说DevOps是一种必须跨越整个IT团队的工作方式，而DevOps团队是不成熟的DevOps组织的标志。 有关更多指导和双方的意见，请参阅：DevOps的经验教训：给IT领导者的建议。\nDevOps 如果改变IT领导力? DevOps不仅会改变IT领导者运行软件项目的方式。 正如美国公民及移民服务部前CIOMark Schwartz写道，“毫无疑问：DevOps代表了一种不同的IT思维模式，并且需要不同的领导模式，”。\n他说，DevOps改变了IT领导力的基本原则，例如如何看待需求，治理和风险。“认为IT只负责“交付”业务部门所希望的或所需要的想法已经过时了。”他说，“相反，CIO必须为推动公司取得成果而加快速度并且勇于承担责任。”\n你应该准备好离开你的舒适区一段时间。“混合或共同的责任，无可指责的事后调查，速度与稳定性的概念经常与你所学的领导IT的原则背道而驰，” 红帽（Red Hat）的产品策略总监Brian Gracely在我们的相关文章中写道 ，7种高效DevOps习惯。\n甚至向团队明确地说明DevOps的目标也很困难。 “你意识到快速交付软件的能力（通过新功能，新产品和新的市场路线）将对业务的未来带来极大的影响，但是你却很难找到一种语言或框架与团队（和同行）进行交流，讨论如何实现DevOps和这些结果。” 请参阅Gracely的文章以获取有关交流的实用建议。\nDevOps 面临的首要挑战是什么？ 与IT经理们交谈后，一个事实很快变得清晰起来：DevOps最困难的部分是相关的文化变革。 你正在打破已经存在多年的边界，重新分配控制权，并挑战专业知识的概念。 对于IT人员，这意味着痛苦和压力 。\n其他主要挑战包括中层管理人员，他们经常为变革设置严峻的障碍，并应对在许多IT组织中存在的大量技术债务。\n正如红帽公司（Red Hat）的CIO Mike Kelly指出：“随着团队变得更具包容性和协作性，领导者必须转变战略和战术，来利用这种新型工作方式所产生的能量。 他们需要完善自己的方法，吸引多方参加对话，并确保每个人的声音都能被听到。 他们需要提高自己的能力，将团队正在做的工作与组织的价值观，目的和目标联系起来，以确保部门中的每个人都明白，组织的价值观是比自己（和自我）更重要的事情中的一部分。 ”\n许多公司在针对特定问题的DevOps项目中获得成功，但后来却难以在整个组织范围内扩展DevOps。 Target的CIO Mike McNamara说，巧妙的启动是关键：“ Target流程的重要组成部分是创建一个加速学习环境，我们的团队称为‘道场‘”，他说。\n“这是一个沉浸式的，为期六周的课程。团队在现场与敏捷教练一起正常工作，敏捷教练支持他们，并提供从DevOps的角度看所需的一切。 “道场”表现出色，使团队参与敏捷和DevOps，消除面临改变的自然阻力和恐惧，然后为团队经历变革提供支持，同时保持生产力。 对于Target而言，这是巨大的成功。 在前进的过程中，我们将继续使用“道场”来完善，增强我们的工程能力。” （请参阅我们的相关文章，Target CIO阐述DevOps如何扎根。）\n数据点：DevOps团队需要变革型领导者：变革型领导者最少的团队，绩效较高的可能性为1⁄2。资料来源：DORA 2017 DevOps状况报告。\n如何处理DevOps文化变革？ 正如Matson的CIO Peter Weis所指出的，任何转型中最苦恼的是人的部分。只要诚实和透明，并得到业务领导层的明确支持，你就可以培育出文化变革。但这需要极大的耐心，Ellucian的CIO Lee Congdon说，这需要极大的耐心，或许还需要共同的主人翁意识\u0026ndash;他认为这也是他的团队文化变革的关键。\n你可能也需要重新考虑头衔和奖励。\u0026ldquo;如果你需要实验性和速度，你需要改变衡量领导者的方式，改变他们报告进展情况的方式和频率，\u0026ldquo;CI\u0026amp;T公司总裁兼联合创始人Bruno Guicardi说。\u0026ldquo;如果你衡量成功的方式要求的是可预测性（Mary必须在Y日期前交付项目X），那么你既得不到速度，也得不到实验性。\u0026rdquo;\n一些CIO，如Adobe CIO Cynthia Stoddard等人说，新的物理环境可以鼓励协作，而Ellucian的Congdon也强调了沟通工具的价值，如Slack。\n最重要的是，你需要每个人的支持，才能让DevOps文化的变革成功，作为Datawire的联合创始人之一的Richard Li说。你需要一种有活力的、自下而上的方法。\nLi建议你从小事做起，用DevOps的工作风格来解决具体的、切实的问题。\u0026ldquo;也许是一个工程师被召唤太频繁了，\u0026ldquo;他说。\u0026ldquo;也许是一个工程师想让数据库在巨大的负载下更有弹性。经理们，问问你的工程师们最烦人或最痛苦的问题是什么：你通常会得到满耳的答复。就从那里开始吧。\u0026rdquo;\n你还想创建论坛，分享团队的成功经验，鼓励工程师们与组织外的其他DevOps专家进行交流。更多的建议，请看Li的文章《培育DevOps文化的5种方法》。\nDevOps度量：如何衡量成功？ 最好的DevOps团队用冷硬的数字来展示他们的成功\u0026ndash;与业务目标一致。\u0026ldquo;完全有可能有这样一个团队，它高效地生产出软件，但没有为企业增加真正的价值，\u0026ldquo;美国国土安全部CTO Michael Hermus最近写道。出于这个原因，他的团队正在追求一套衡量标准，其中将包括威胁检测的准确性等措施，这对他的团队来说是关键。\n事实上，许多团队在开始DevOps度量工作时，都会通过收集效率和速度措施的数据，如正常运行时间、每秒事务处理量、修复的Bug等，来开始DevOps的度量工作。Red Hat技术布道师Gordon Haff说：但这并不能让它们成为度量。同时他指出\u0026quot;度量被正确地认为是数据的一个关键“绩效”KPI指标\u0026ndash;一个以某种基本方式对你来说很重要的度量\u0026rdquo;。\n他说：\u0026ldquo;寻求为你的组织确定不超过10个这样的指标，最好是更少。除了你可以从计算机系统中收集到的更明显的运营和发展数据外，还可以考虑那些能够发现更广泛的组织或流程健康问题的指标。\u0026rdquo;\n例如，您的企业可能正在寻求提升客户体验和运营效率。对于客户体验，像Net Promoter Score这样的指标可能是合适的。客户订单量（作为整体客户满意度的指标）和开发人员工作满意度评分（考虑到吸引和留住DevOps明星的难度）是另外两个需要考虑的评分。更多建议，请参阅我们的相关文章《DevOps指标：你衡量的是重要的因素吗？》。\nDevOps是否意味着你不需要项目经理？ 简而言之：不，DevOps的讨论往往集中在开发人员和运营团队上，但项目经理在DevOps时代会生存下来，并经历巨大的变革。\n正如我们最近的文章《如何重新思考DevOps的项目管理》中指出的那样。\u0026ldquo;DevOps从根本上改变了IT团队如何对待项目的方式，从单一的、多月（或在某些情况下是多年）的项目转移到追求软件开发生命周期中更快、更敏捷的速度和敏捷性。这对项目经理来说意味着改变。但不要搞错了，项目经理在DevOps时代仍然可以发挥出价值。\u0026rdquo;\n\u0026ldquo;传统上，项目管理更多的是单一化和瀑布式的方法驱动，\u0026ldquo;CYBRIC联合创始人兼首席技术官Mike Kail说。\u0026ldquo;随着DevOps转型，PMO功能需要采取\u0026rsquo;微服务\u0026rsquo;的方式，由于子项目较小，所以能够实现更高的速度。\u0026rdquo;\n\u0026ldquo;随着交付速度的提高，依赖性的重视也随之增加，\u0026ldquo;Janeiro Digital的技术架构师Josh Collins说。 \u0026ldquo;现在，从上游团队集成一些东西，或者从利益相关者那里得到一个完整的需求，部署之间的间隔时间更少了。\u0026rdquo; 他说，Scrum方法论和看板等工具可以在这里有所帮助。更多内容，请参阅《如何重新思考DevOps的项目管理》。\nDevOps安全性：如何避免风险？ 当然，在引入速度的同时，DevOps团队必须避免引入不必要的安全风险。因此，企业IT越来越重视 \u0026ldquo;DevSecOps\u0026rdquo;，团队将安全构建到整个软件开发生命周期中\u0026ndash;从早期开始，就已经开始了。\n\u0026ldquo;DevSecOps不仅仅是工具，它是在早期就将安全思维融入到开发实践中，\u0026ldquo;Sonatype公司副总裁、DevOps倡导者Derek Weeks说。\nRed Hat安全策略师Kirsten Newcomer表示，这引入了另一个文化挑战。\n\u0026ldquo;安全团队在历史上一直与开发团队隔绝\u0026ndash;每个团队都在不同的IT领域发展了深厚的专业知识，\u0026ldquo;Newcomer说。\u0026ldquo;它不需要这样。深切关注安全的企业，同时也非常关注通过软件快速交付业务价值的能力，他们正在寻找在应用开发生命周期中将安全性左移的方法。他们正在通过将安全实践、工具化和自动化整合到整个CI/CD流水线中，从而采用DevSecOps。\u0026rdquo;\n\u0026ldquo;为了做好这一点，他们正在整合他们的团队\u0026ndash;安全专业人员与应用开发团队从开始（设计）到生产部署的过程中，都会融入到到应用开发团队中。\u0026ldquo;她说。\u0026ldquo;双方都看到了价值\u0026ndash;每个团队都扩大了他们的技能集和知识库，使他们成为更有价值的技术专家。做得好的DevOps\u0026ndash;或者说DevSecOps\u0026ndash;提高了IT安全。\u0026rdquo;\n关于如何击败文化冲突和加强安全的详细建议，还可以查看我们的相关文章《DevOps与安全：结束文化冲突的4个步骤》，作者是DigiCert的CTO Dan Timpson。\nDevOps发展趋势：接下来会发生什么？ DevOps在企业中的发展方向如何？最近，我们与DevOps leaders讨论获得以下几个方面趋向\n首先，企业将DevOps与云服务(按需使用计算和存储能力),容器和微服务结合使用。\n“容器，DevOps和微服务可以组合在一起，以帮助CIO实现敏捷目标.” Red Hat副总裁兼OpenShift总经理Ashesh Badani 表示：” 简而言之，容器将应用程序打包成一个个分离的程序包，与运行的操作系统相互隔离。在DevOps基础组成部分，开发人员更容易切换的开发环境。容器更快地协助你将代码部署到生产环境中。” （有关更多信息，请参见相关文章《4种容器采用模式。你需要知道的是什么》）\n因此，团队需要了解容器、微服务和云服务之间日益增长的相互依赖关系-这种组合可以帮助DevOps专业人士进行安全、快速的验证和运行。DevOps团队将需要管理和扩展微服务框架，诸如Kubernetes之类的编排工具，获得赢得他们青睐。\n其次，您可预期DevOps的工作方式会从开发、运维和安全延伸到DB团队(数据库团队)，QA(质量团队)，甚至IT领域外的团队。\n“DevOps首要做的一件事：识别摩擦点并解决它们，” 达蒂埃里夫斯表示。“对于已采用DevOps的公司来说，安全和数据是当前最大的瓶颈。”\n此外，还要寻找投资回报率的衡量标准和成功指标，以谋求更好地发展。 “我相信DevOps文化的两个核心原则：自动化和度量永无止境。” CYBRIC公司的首席技术官Mike Kail表示。 “总是有机会实现自动化任务或改进已存在的自动化解决方案，而重要的衡量指标可能会随着时间的推移而改变和扩展。这个成熟过程是持续之旅，而不能看作为一个目标或一项的任务。” 有关更多信息，请参见我们的相关文章《DevOps的下一步是什么：5个需要关注的趋势》。另外，请看《2018年5个DevOps领导力优先事项》。\n数据表示：在美国，DevOps工程师的平均薪水$104,508(中位数$110,000)\n数据来源：Glassdoor招聘网(https://www.glassdoor.com/index.htm)。\nDevOps职位：就业前景如何？ 总而言之：竞争。多家公司竞争DevOps人才。Linux基金会和技术工作站Dice进行2017年报告显示：60％的招聘经理正招聘DevOps人才。它是仅次于开发职位（73％），成为年度最受欢迎的职位。由于竞争激烈，大多数公司内部培养、教授渴望成为DevOps工程师的人去适应新的工作方式，成为至关重要。同时新的人才流失问题也成为焦点。 尽管您找到大量“ DevOps工程师”招聘广告，但现在更多的人在DevOps环境中工作而没有DevOps头衔。\n在未来，DevOps团队会担任更多专家角色。“从最初的构想来看，DevOps通常被认为（有时是实施）是消除专家角色，”Red Hat技术布道师Gordon Haff说。“每个人都可以开发，也可以运维，每个人都可以随时响应。”\n“但是，特别是在大型组织中，这并不总是有效的。” 他解释说：“筒仓型组织将会被分解。很难与多学科团队抗衡。但是，在安全和大型基础设施等领域始终需要专家。关键是这些领域专家如何高效地与他人沟通和提供工具与他人使用。”\n尤其成熟度高的DevOps团队，他们将自定义角色和流程，以更好地解决组织的需求和业务战略。Ben Newton(Sumo Logic分析负责人)表示。“我认为，DevOps的发展趋势更加适合于现代组织，核心是确定除了开发团队/ Scrum团队所需要专业化知识，以构建、支持他们的代码。”\n他希望在DevOps中增加类似可靠性工程师，安全架构师、专家 和多种多样的的迭代QA /测试工程师角色。\n他补充说：“由于分析能力对今天的竞争力至关重要，因此我们也希望更多以数据科学为导向的工程师在推动发展。” 请参阅我们的相关文章《DevOps 工作: 4个值得关注的趋势》。\n另外，请查看我们的《DevOps求职者和招聘经理系列》，其中对转型DevOps，投简历等方面的技巧提供提示。\n从哪里了解DevOps的更多信息？ 想知道更多吗？我们为尝试培养IT leaders的DevOps专业知识的，已经准备一些文章清单 。\n 高效DevOps的7个习惯 依托云和DevOps的SunTrust的SunTrust CIO加速范式 CIO诠释DevOps如何扎根于零售业巨头 这种转型模型赋能Vanguard IT加速和创新 CBRE’s DevOps学习之旅 培养DevOps文化的5种方法 DevOps职位：如何找到出色的DevOps商店 DevOps的9个关键词 DevOps入门的5种最佳实践（Opensource.com） 麦格理（Macquarie）通过Red Hat OpenShift转型数字银行业务（Red Hat白皮书） 您应该了解的数字转型知识（Red Hat video） 训练”大象”跳舞（Red Hat ebook on DevOps culture change） IT文化变革指南 采用DevOps的5个障碍    ","permalink":"https://devopschina.org/blog/devops-it-leaders-guide/","tags":["DevOps"],"title":"DevOps：IT领导者指南"},{"categories":["翻译"],"contents":" 社区译者：尚君领 朱露露 刘海燕 周一行\n审校：王立杰 王英伟 高俊宁 陈文峰\n原作者：Martin Fowler 原文地址：https://martinfowler.com/articles/continuousIntegration.html\n 摘要 持续集成是一种软件开发实践，团队成员频繁地将他们的工作成果集成在一起，通常每人每天至少提交一次，这样每天就会有多次集成。每次集成都通过自动构建(包括测试)进行验证，以便尽可能快地检测集成错误。许多团队发现这种方法可以显著减少集成问题，并允许团队更快地开发内聚软件。本文简要介绍了持续集成技术及其应用现状。\n引言 我清楚地记得我第一次看到一个大型软件项目。那时我在英国一家大型电子公司做暑期实习。我的经理，QA小组的一员，带我参观了一个地方，我们进入了一个令人沮丧的大仓库，里面堆满了立方体。我被告知这个项目已经开发了几年，目前正在集成，并且已经集成了几个月。他告诉我，没有人真正知道完成集成需要多长时间。从中我学到了软件项目的一个共同的故事：集成是一个漫长而不可预测的过程。\n其实不需要这样。我在ThoughtWorks的同事和世界上许多其他人所做的大多数项目都不把集成当成一个很严重的事儿。任何单个开发人员的工作都离共享的项目状态只有几个小时，并且可以在几分钟内集成回去。任何集成错误都能被快速发现并得到迅速修正。\n这种鲜明的对比并不是昂贵复杂工具的结果。它的本质在于一个简单的实践，也就是团队里的每个人都在频繁的集成，通常是每天对于一个受控的源代码存储库进行集成。\n当我向人们描述这一做法时，我通常会发现两种反应：“这里不行”和“这样做不会有多大区别”。人们在尝试的过程中发现，这比听起来容易得多，而且对开发有着巨大的影响。因此，第三种常见的反应是“是的，我们这样做了——没有它你怎么活？”\n术语“持续集成”起源于Kent Beck的极限编程开发过程，是最初的12个实践之一。当我开始在ThoughtWorks工作时，作为一名顾问，我鼓励在我工作的项目中使用这种技术。Matthew Foemmel把我模糊的建议变成了实际行动，我们看到了这个项目从罕见而复杂的集成，变为我描述的不是那么严重的事情。Matthew和我在这篇论文的原始版本中写下了我们的经验，这篇论文一直是我网站上最受欢迎的论文之一。\n尽管持续集成是一种不需要特殊工具来部署的实践，但我们发现使用持续集成服务器是很有用的。最著名的此类服务器是CruiseControl，这是一个开源工具，最初由ThoughtWorks的几个人构建，现在由一个很大的社区维护。从那时起，出现了其他一些CI服务器，有开源的，也有商用的——包括ThoughtWorks工作室的Cruise。\n使用持续集成构建功能 对于我来说，解释什么是CI以及它是如何工作的最简单的方法是展示一个快速的例子，说明它如何与一个小特性的开发一起工作。假设我必须对一个软件添加一点功能，任务是什么并不重要，因为现在我假设它很小，可以在几个小时内完成。（稍后我们将探讨更长的任务和其他问题。）\n首先，我将当前集成源代码的副本复制到本地开发机器上。我通过使用源代码管理系统，从主干签出一个工作副本来实现这一点。\n上面那段话对于使用源代码控制系统的人来说是有意义的，但是对于不使用源代码控制系统的人来说是胡言乱语。所以让我快速地为后者解释一下。源代码控制系统将项目的所有源代码保存在存储库中。系统的当前状态通常称为“主干”。开发人员可以随时在自己的机器上生成主干的受控副本，这称为“签出”。开发人员机器上的副本称为“工作副本”。（大多数情况下，你实际上是把你的工作副本更新到主干上——实际上和签出也是一样的。）\n现在我拿着我的工作副本，做任何我需要做的事情来完成我的任务。这将包括修改产品代码，以及添加或更改自动化测试。持续集成假定软件中有高度自动化的测试：我称之为自测试代码的工具。它们通常使用流行的XUnit测试框架的一个版本。\n当我完成之后（通常在我工作的不同阶段），我就在我的开发机器上执行一个自动化的构建。这将获取工作副本中的源代码，将其编译并链接到可执行文件中，然后运行自动测试。只有在所有的构建和测试都没有错误的情况下，整个构建才被认为是正确的。\n有了正确的构建，我就可以考虑将更改提交到存储库中。当然，问题是，在我有机会提交我的更改之前，其他人可能，而且通常已经对主干进行了更改。因此，首先我用他们的更改来更新我的工作副本，并重新构建。如果他们的更改与我的更改冲突，在编译或测试中将显示为失败。在这种情况下，我的责任是修复这个问题，并重复构建，直到我可以建立一个与主干正确同步的工作副本。\n一旦我自己构建了一个正确同步的工作副本，最终我就可以将我的更改提交到主干中，之后会更新存储库。\n然而，我的提交并没有完成我的工作。此时，我们再次构建，但这次是在基于主干代码的集成服务器上。只有当这个构建成功时，我们才能说我的更改已经完成。因为总有万一，我可能会遗漏了我的机器上的东西，存储库没有得到适当的更新。只有当我提交的更改在集成服务器上成功构建时，我的工作才能完成。这个集成构建可以由我手动执行，也可以由Cruise自动完成。\n如果两个开发人员之间发生冲突，通常会在第二个提交的开发人员构建其更新的工作副本时捕获冲突。否则，集成构建将失败。无论哪种方式，错误都会被快速检测到。此时，最重要的任务是修复它，并使构建重新正常工作。在持续集成环境中，不应该让失败的集成构建保持在失败状态太久。一个好的团队一天应该有很多正确的构建。不好的构建时有发生，但应该迅速被修复。\n这样做的结果是，有一个稳定的软件，工作正常，包含很少的错误。每个人都是从这个共享的稳定的基础上开发的，从来没有离开这个基础太远，以至于需要很长时间才能集成回来。寻找错误会花更少的时间，因为错误很快就会显现出来。\n持续集成的实践 上面的故事是关于CI的概述，以及它在日常生活中是如何工作的。显然，让所有这些工作顺利进行并不仅仅是这些。我现在将重点介绍构成有效CI的关键实践。\n维护单一的源代码存储库 软件项目涉及许多需要组合在一起才能构建产品的文件。跟踪所有这些文件，是一项重要的工作，特别是当有多人参与时。因此，我们毫不意外的看到，多年来，软件开发团队已经构建了管理所有这些文件的工具。这些工具称为源代码管理工具、配置管理、版本控制系统、存储库或各种其他名称，是大多数开发项目不可分割的一部分。令人悲哀和惊讶的是，它们并不是所有项目的一部分。尽管很少见，但我确实遇到不使用这样的系统的项目，项目使用一些混乱的本地和共享存储器的组合。\n因此，作为一个简单的基础，确保你要有一个像样的源代码管理系统。成本不是问题，因为有高质量的开源工具。当前选择的开源存储库是Subversion。（较老的开源工具CVS仍然被广泛使用，虽然比什么都没有要好得多，但是Subversion是更时髦的选择。）有趣的是，当我与开发人员交谈时，我了解到大多数商业源代码管理工具比Subversion更受欢迎。我一直听到人们说唯一值得花钱的工具就是Perforce。（译者注：本文写于2006年，时至今日，Git更为流行）\n一旦你得到一个源代码管理系统，确保它位于众所周知的地方，每个人都去获取源代码。没有人会问“foo-whiffle文件在哪里？”所有的东西都应该在存储库里。\n尽管许多团队都会使用存储库，但我发现一个常见的错误是，他们没有将所有内容都放在存储库中。如果人们使用它，他们会把代码放在那里，但你的构建需要做的一切都应该在那里，包括：测试脚本，属性文件，数据库架构，安装脚本和第三方库。我知道一些项目，将编译器检入到存储库（对于早期的大量的C++编译器很重要）。基本的经验法则是，你应该能够用一台空白的机器开始项目，做一个签出，并且能够完整的构建系统。只有少量的东西应该放在空白的机器上，通常是大的、安装复杂的和稳定的东西。操作系统、Java开发环境或基础数据库系统是典型的例子。\n你必须将构建所需的所有内容都放在源代码管理系统中，但是你也可以将人们通常使用的其他内容放在其中。IDE配置很适合放在那里，因为这样人们就可以很容易地共享相同的IDE设置。\n版本控制系统的一个特点是，它们允许你能创建多个分支，以处理不同的开发流。这是一个有用的，但不必要的功能，但它经常被过度使用，并使人们陷入麻烦。尽量少用分支。特别是在有一条主干的情况：目前正在开发的项目的唯一分支。几乎每个人大部分时间都应该在这条主干上工作。（合理的分支是修复先前生产版本的错误和临时的实验。）\n一般来说，你应该在源代码管理中存储构建所需的所有内容，但不存储实际构建出的内容。有些人确实将构建的产品放在源代码管理中，但我认为这是一种坏味道——这意味着更深层次的问题，通常是无法可靠地重新创建构建。\n构建自动化 将源代码转换为可以运行的系统，通常是一个复杂的过程，它包括编译、移动文件、把数据库模式加载到数据库等等。然而，与软件开发中的大多数任务一样，它是可以被自动化的。它也应该是自动化的。让人们输入奇怪的命令或点击对话框是浪费时间，也最容易产生错误。\n构建自动化环境是系统中一个共同的特性。Unix世界使用make作为工具已经几十年了，Java社区发展了ANT（译者注：后来JAVA的构建工具发展为Maven和Gradle），并且. net社区已经有了Nant，现在又有了MSBuild。确保你可以使用单个命令使用这些脚本构建和运行启统。\n一个常见的错误是没有在自动化构建中包含所有内容。构建应该包括从存储库中获取数据库模式，并在执行环境中启动它。我将详细阐述我先前的经验法则：任何人都应该能够引入一台空白机器，签出存储库中的源代码，发出一个命令，之后在自己的机器上就拥有了一个正在运行的系统。\n构建脚本通常有不同的风格，通常是特定于平台或社区的，但他们大可不必如此。尽管我们的大多数Java项目都使用Ant，有一些在使用Ruby（Ruby Rake是一个非常好用的构建脚本的工具）。我们通过使用Ant自动化在早期的微软 COM项目中获得了某些价值。\n一个大的构建通常需要花费很多精力，如果你仅仅做了一个小小的更改，那么你不会想要执行所有的步骤。所以，一个好的构建工具会分析在流程中需要更改的内容。通常的做法是检查源文件和目标文件的日期，只有在源文件的日期较晚时才进行编译。依赖关系会变得更加棘手：如果一个对象文件改变了那些依赖于它的对象文件，那么这些对象文件可能也需要重新构建。编译器能够处理这类事情，也可能不处理。\n根据你的需要，你可以构建不同类型的东西。你可以通过是否使用测试代码或者使用不同的测试集来构建系统。有些组件可以独立构建。构建脚本应该允许你为不同的情况构建可选目标。\n我们普遍使用IDE，而且在使用IDE时，大多数的公司内部都有一些构建管理的过程。然而，这些文件总是IDE专有的，而且它们非常脆弱。不过，他们这些公司需要通过IDE进行工作。用户通过IDE设置自己的项目文件并将其用于单独的开发是完全没有问题的。然而，有一个在服务器上可用并且可以从其他脚本运行的主干是非常重要的。所以在Java项目中，我们可以让研发人员在IDE中构建，但是主干需要使用Ant来保证它可以在开发服务器上运行。\n如何构建自动化测试 从传统意义上来讲，构建意味着编译，链接以及执行程序所需的所有其他过程。一个项目可能会运行，但是，这并不意味着它在做正确的事情。现代静态类型语言可以发现许多bug，但是更多的bug会成为“漏网之鱼”。\n在构建过程中包含自动化测试是更快、更有效地发现bug的比较好的方法。当然，测试并不是完美的，但它能够发现很多Bug，这就足够有用了。特别是极限编程(XP)和测试驱动开发(TDD)的兴起为自动化测试的普及做了大量工作，因此许多人已经看到了这种技术的价值。\n经常阅读我作品的读者会发现我是XP和TDD的忠实粉丝。然而，我想要强调的是，这两种方式都不是构建自动化测试的最佳途径。这两种方式都强调在使测试通过之前你要先编写测试——在这种模式下，测试不仅能够用于发现错误，而且还涉及探索系统的设计。这是一件好事情，但是，对持续集成而言，这并不是必需的。因为我们通常对自动化测试代码的需求比较少。（尽管TDD是我进行自动化测试的首选）\n对于自测试代码而言，你需要一套自动化测试体系它可以检查大部分代码库中的Bug。测试可以从一个简单的指令中启动并进行自动检测。运行测试套件的结果应该可以指出是否有任何测试失败。对于具备自测试的构建，测试的失败应该会导致构建失败。\n在过去的几年时间里，TDD的兴起普及了XUnit开源工具家族，这些工具对于这类测试非常理想。Xunit 工具对我们 ThoughtWorks 来说非常有价值，我也总是建议人们使用这些工具。这些由Kent Beck首创的工具，能够帮你非常容易的构建一个自动化测试环境。\nXUnit工具当然是让代码进行自动化测试的起点。你也应该寻找其他专注于更多端到端测试的工具。目前有很多这样的工具，包括FIT、Selenium、Sahi、Watir、FITnesse，还有很多其他工具，我在这里不打算都列出来。\n当然，你不能指望测试能发现一切错误。正如人们常说的那样:测试并不能证明没有缺陷。虽然你从自动化测试的构建中得到的反馈并不一定是完美的，经常运行的不完美的测试也比根本不写的完美测试要好得多。\n每人每天都向主干提交代码 集成主要是关于沟通的。集成允许开发人员将他们所做的更改告知其他开发人员。频繁的交流能让人们在变化发生时迅速了解情况。\n开发人员遵守主干的一个先决条件是，他们可以正确地构建自己的代码。当然，这包括通过构建测试。与任何提交周期一样，开发人员首先更新其工作分支以匹配主干，解决与主干的任何冲突，然后在其本地上构建。如果构建通过，那么他们可以自由地提交到主干上。\n通过经常这样做，开发人员可以快速发现两个开发人员之间是否存在冲突。快速修复问题的关键是快速找到它们。由于开发人员每隔几小时就提交一次冲突，所以在冲突生后的几小时内就可以检测到，此刻没有发生太多代码修改，所以容易解决。持续数周不被发现的冲突，可能很难解决。\n在更新工作分支时进行构建，这一事实意味着可以同时检测到编译冲突和文本冲突。由于构建是自测试的，所以你还可以检测代码运行中的冲突，如果后一种Bug在代码中存在了很长时间而没有被发现，那么它们是特别难以发现的错误。由于两次提交之间只有几个小时的更改，所以问题隐藏的地方也就只有那么多了。此外，由于没有太大的变化，你可以使用差异调试来帮助你找到错误。\n我的一般经验法则是，每个开发人员每天都应该提交到代码库。在实践中，如果开发人员更频繁地提交，通常是有用的。提交的频率越高，寻找冲突错误的地方就越少，解决冲突的速度也就越快。\n频繁的提交会鼓励开发人员将他们的工作分解成几个小时的小块。这有助于跟踪进度，并提供一种进度感。通常人们一开始觉得他们不能在几个小时内做一些有意义的事情，但是我们发现指导和练习可以帮助他们学习。\n每次提交都应该在集成机器上构建主线 通过使用每日构建，团队可以得到频繁的测试构建。这应该意味着主干保持在健康的状态。然而，在实践中，依然有出错的情况。一个原因是纪律，人们没有在提交之前进行更新和构建。另一个原因是开发人员使用的机器之间的环境差异。\n因此，你应该确保常规构建发生在集成机器上，并且只有在此集成构建成功时，才应该认为提交已经完成。由于开发人员对提交的代码负责，所以该开发人员需要监视主干构建，以便在它崩溃时进行修复。这样做的一个推论是，你如果在当天晚些时候提交了一些改动，那么在主干构建通过之前你不能回家。\n我见过两种主要的方法来确保这一点：使用手动构建或持续集成服务器。\n手工构建方法是描述起来最简单的方法。本质上，它类似于开发人员在提交到存储库前进行的本地构建。开发人员走到集成计算机，签出主线的头部(现在存放他的最后提交)，并开始集成构建。他会密切关注构建的进展，如果构建成功，他就完成了提交。(参见Jim Shore的描述。)\n持续集成服务器充当存储库的监视器。每次完成对代码库的提交时，服务器都会自动将源签出到集成机器上，启动构建并将构建的结果通知提交者。直到提交者收到通知——通常是一封电子邮件——它才算完成。\n在ThoughtWorks，我们是持续集成服务器的忠实粉丝——事实上，我们领导了CruiseControl和CruiseControl.NET的起初的开发，他们是被广泛使用的开源CI服务器。从那时起，我们还建立了商业版的Cruise CI服务器。我们几乎在每个项目上都使用CI服务器，并且对结果非常满意。\n并不是所有人都喜欢使用CI服务器。吉姆·肖尔(Jim Shore)对他为什么更喜欢手工方法给出了一个颇有争议的描述。我同意他的观点，CI不仅仅是安装一些软件。这里的所有实践都需要有效地进行持续集成。但是，同样有许多优秀的CI团队发现CI服务器是一个有用的工具。\n许多组织按照定时计划进行定期构建，比如每天晚上。这与持续构建不同，对于持续集成来说还不够。持续集成的全部意义在于尽快发现问题。夜间构建意味着bug在被发现之前一整天都没有被发现。一旦它们在系统中存在了那么长时间，就需要花费很长时间才能找到并修复它们。\n立即修复失败的构建 做持续构建非常关键的一点就是一旦主线构建失败就要立即修改它。使用CI的意义就在于，你总是能在已知稳定基础上进行开发。主线构建失败是常有的事，且也并不是什么坏事，但这却能够表明人们在提交代码之前对本地的更新和构建不够小心。然而，当主线构建确实中断时，快速修复它就变得极为重要。\n我记得Kent Beck说过一句话：“没有人拥有比修复失败的构建更高的优先级任务”。但也不必团队中的每个人都必须停止他们手头的工作来修改失败的构建，通常只需要几个人就可以成功修复。我们要有意识的将修复构建作为一个紧急的、高优先级的任务进行优先排序。\n通常，修复构建的最快方法是从主线还原到最新一次已知的、良好的构建提交状态。当然，团队不应该在构建失败的主线上进行任何调试。除非失败的原因很明显，否则只需恢复主线然后在开发工作站上调试问题。\n为了避免破坏主线，你可以考虑使用pending head。\n当团队引入CI时，这通常是最难解决的问题之一。在早期，团队很难养成处理主线构建的常规习惯，特别是在处理现有代码库时。耐心和坚持不懈的努力看起来确实经常起作用，，所以不要气馁。\n保持快速构建 持续集成的关键是提供快速的反馈。没有什么比一个需要很长时间的构建更能危害CI的活动了。在这里我必须承认有一些古怪的老员工把长时间的构建当成娱乐。我的大多数同事认为一个需要一个小时的构建是完全不合理的。我记得一些团队梦想着他们能以如此之快的速度完成任务——但是有时候我们仍然会遇到这样的情况：很难以这样的速度完成任务。\n然而，对于大多数项目来说，十分钟构建的XP指导方针是完全合理的。现在我们的大多数项目都实现了这一点。这值得我们集中精力来实现它，因为每减少一分钟的构建时间，那么对于每个开发人员的每次提交都会节省一分钟的时间。由于CI需要频繁提交，这就会增加很多的时间。\n如果你一开始就需要一个小时的构建时间，那么获得更快的构建可能会让人畏惧。甚至在一个新的项目上工作，并思考如何让事情保持快速也会让人畏惧。至少对于企业应用程序，我们发现通常的瓶颈是测试——特别是涉及外部服务（如数据库）的测试。\n最关键的一步是开始建立部署流水线。部署流水线（也称为构建流水线或分阶段构建）背后的思想是，实际上有多个按顺序完成的构建。对主线的提交触发了第一个构建——我称之为提交构建。提交构建是当有人需要提交到主线时所需的构建。提交构建是必须快速完成的构建，因此它将采用许多快捷方式，这将降低检测错误的能力。关键在于平衡发现bug的能力和速度的需求，这样一个好的提交构建就足够稳定，可以供其他人工作使用\n一旦有良好的提交构建，其他人就可以满怀信心地处理代码。不过，你可以开始做更多、更漫长的测试。其他机器可以在构建上运行需要更长时间的测试程序。\n这是一个简单的两阶段部署流水线例子。第一阶段将进行编译并运行更本地化的单元测试，数据库通过“打桩”的方式完全被隔离掉。这样测试可以运行得非常快，保持在10分钟的范围内。但是，任何涉及大规模交互的bug，特别是涉及真实数据库的bug，都很难被发现。第二阶段构建运行一组不同的测试，这些测试确实会测试真实的数据库，并涉及更多的端到端行为。这一次运行可能需要几个小时的时间。\n在这个场景中，人们使用第一个阶段作为提交构建，并使用它作为主CI周期。第二阶段构建在可能的情况下运行，从最近的良好提交构建中获取可执行文件以进行进一步的测试。如果这个二次构建失败，那么它可能没有 “停止一切”的质量目标，但是团队的目标是在保持提交构建运行的同时，尽快修复此类错误。在这个例子中，后面的构建通常是纯测试，因为现在通常是测试导致了缓慢。\n如果第二级构建检测到一个bug，这表明提交构建可能使用另一套测试。尽可能地确保任何后期阶段的失败，都会触发在提交构建中引入新的测试，这样在提交构建中就能捕获bug，从而在提交构建中就能解决掉这些bug。这样，每当有错误漏过提交时，提交测试就会加强。在某些情况下，没有一种快速运行的测试来暴露bug，因此你可能决定只在第二级构建中测试该条件。幸运的是，大多数情况下，你可以向提交构建添加适当的测试。\n这个例子是一个两级流水线，但是基本原理可以扩展到任何后期阶段。提交构建之后的构建也可以并行完成，因此如果有两个小时的第二阶段测试，则可以通过让两台机器分别运行一半的测试来提高响应速度。通过使用类似这样的并行第二阶段构建，你可以将进一步的自动化测试（包括性能测试）引入到常规构建过程中。\n在生产环境的克隆中测试 测试的重点是在受控条件下，清除系统在生产中可能出现的任何问题。其中很重要的一部分是生产系统运行的环境。如果你在不同的环境中进行测试，每一个差异都会导致风险，即在测试中发生的事情不会在生产中发生。\n因此，你希望将测试环境设置为尽可能精确地模拟生产环境。使用相同版本的数据库软件，使用相同版本的操作系统。将生产环境中的所有适用的库放入测试环境中，即使系统实际上没有使用它们。使用相同的IP地址和端口，在相同的硬件上运行它。\n事实上，这是有限度的。如果你正在编写桌面软件，使用不同人员运行的、并安装了所有的第三方软件的桌面克隆中，进行测试那是不现实的。类似地，有些生产环境的复制成本可能高得令人望而却步（尽管我经常遇到不复制中等成本的环境而产生的浪费成本）。尽管存在这些限制，你的目标仍然应该是尽可能多地复制生产环境，并理解测试和生产之间的每一个差异所带来的风险。\n如果你有一个非常简单的设置，而没有许多笨拙的通信，那么你可以在模拟的环境中运行提交构建。但是，通常需要使用测试替身(test double)，因为系统响应缓慢或不够稳定。因此，通常都有一个非常人工的环境来进行提交测试，以提高速度，并使用生产克隆进行辅助测试。\n我注意到越来越多的人对使用虚拟化来简化测试环境的组合越来越感兴趣。虚拟化的机器可以保存在虚拟化中的所有必要元素中。安装最新的构建和运行测试相对简单。此外，这还允许你在一台计算机上运行多个测试，或者在一台计算机上模拟网络中的多台计算机。随着虚拟化的性能损失降低，这个选项变得越来越有意义。\n使任何人都能轻松获得最新的可执行文件 软件开发中最困难的部分之一是确保你构建了正确的软件。我们发现，很难事先明确自己想要什么，也很难做到正确；人们更容易看到不太正确的东西，并说出需要如何改变。敏捷开发过程明确地期望并利用人类行为的这一部分。\n为了帮助实现这一点，任何参与软件项目的人都应该能够获得最新的可执行文件并能够运行它：用于演示、探索性测试，或者只是看看本周发生了什么变化。.\n这样做非常简单：确保有一个众所周知的地方，人们可以找到最新的可执行文件。在这样的存储中放置几个可执行文件可能是有用的。对于最新的可执行文件，你应该放置最新的可执行文件以通过提交测试—如果提交套件相当强大，那么这样的可执行文件应该相当稳定。\n如果你正在使用定义良好的迭代来跟踪一个流程，那么通常明智的做法是将迭代构建的结束也放在流程里。特别是演示，需要的是让人熟悉功能的软件，因此通常为演示者知道如何操作的，而牺牲最新的一些事是值得的。\n每个人都可以看到正在发生什么 持续集成就是为了沟通，所以你希望保证每个人都能很方便的看到系统当前的状态以及在系统上所做的改变。\n其中用于沟通的最重要的一个途径是主线构建的状态。如果你使用 Cruise(现改名为GoCD)，那么有一个网站可以展示给你看是否有个构建正在进行，以及最后一次主线构建的状态。很多团队喜欢将持续显示和构建系统连接起来，从而使它更显而易见。通常用灯来表示：绿灯表示构建成功，当失败的时候则亮红灯。常见的一个设计是红色和绿色的熔岩灯—不仅仅给出这些构建状态的指示，而且还指示已经处于该种状态多久了。红色熔岩灯上的气泡表明此次构建已经失败很久了。每个团队都可以自己选择构建传感器—当然你的选择也可以是很好玩的（最近我看到有人在用一只跳舞的兔子）。\n即使你使用手动的持续集成，可视化依然很重要。物理构建机器的监视器可以展现主线构建的状态。通常可以给正在构建的人的桌子上放一个构建令牌（再说一次，像橡胶鸡这样的蠢东西也是一个很好的选择）。人们常常喜欢给构建成功加上一点简单的噪音，比如说铃声。\n当然，持续集成服务器的网页可以承载更多的信息。Cruise 不仅能提供谁正在构建，而且还能提供他们做了什么改变。Cruise还可以提供改变的历史，以使得团队成员可以对当前项目中最近的行为有更好的了解。我知道团队的领导喜欢用这些信息来了解团队成员在做什么以及保持对系统改变的感知。\n使用网站的另外一个优势是那些异地办公的成员可以获知项目状态。一般来说，我倾向于积极紧密工作在同一个项目上的成员坐在一起，但是经常还会有一些其他人员关心项目的相关事宜。同时对于组织将多个项目的构建信息聚合在一起也是很有用的—可以为不同的项目提供一个简单并且自动的状态。\n好的信息展示不仅仅是电脑屏幕上那些。我最喜欢的一个信息展示来自一个使用持续集成的项目上。它在一个很长的时间里不能稳定构建。我们把一整年的日历放到墙上，用一个方框表示一年中的一天。如果QA团队得到一个通过了提交测试的稳定的构建，他们会把一个绿色的贴纸放到这一天的方框里，反之则放一个红的贴纸。随着时间过去，日历揭示了构建过程持续改善的情况，直到绿色的方框越来越多的时候，日历就消失了—因为达到了它的目的。\n自动化部署 为了做持续集成，你需要多个环境，一个用来运行提交测试，一个或者多个用来运行第二阶段测试。因为你每天都要在这些环境之间移动可执行文件很多次，所以你希望能自动的做这些事儿。很重要的是你要有一些脚本可以很容易的把应用部署到任意环境中去。\n这么做很自然的结果就是你还应该有脚本，以使得你可以同样简单的部署到生产环境。你可能不会每天都部署到生产环境（虽然我曾经参与过这样的项目），但是自动化部署可以帮助你提高速度并且减少错误。这同样是一个便宜的选项，因为这只是使用了你用于部署到测试环境的相同资源。\n如果你在生产环境自动部署，那么你需要考虑的一个额外的功能是自动回滚。糟糕的事情随时会发生，如果发臭的棕色物质撞到旋转的金属上（情况不妙），最好能够很快的回到最后一个已知的好的状态。能够自动回滚，可以大大减少部署产生的紧张感，鼓励人们更频繁的部署，因此我们可以更快的把新特性提供给用户。（Ruby on Rails社区开发了一款名为Capistrano的工具，是做此类事情的工具的一个好例子）\n在集群环境中我看到滚动部署，新的软件会一次部署到一个节点，然后在几个小时内慢慢将整个应用替换掉。\n对于面向大众的网站应用，我接触到的一个很有趣的部署方式是：将一个试用版本部署给部分用户。接着团队可以观察该试用版本是如何被使用的，然后决定是否将其部署给全量用户。这使得你可以在做出最终选择之前测试新特性和用户接口。自动化部署结合良好的持续集成原则，是此工作的重要基础。\n持续集成的好处 总起来说我认为持续集成最显著也是最宽泛的好处在于减少了风险。我又想起了在本文第一段中提到的软件项目。团队已经处于一个漫长项目的末期（起码他们是这么认为的），但是还没法判断距离项目真正做完还有多久。\n推迟集成的麻烦在于很难预测到底需要多久来做这件事儿，并且更糟糕的是甚至很难看到你在这个过程中的进展。结果就是，即使你是少数几个还没延迟的案例之一，你也会在项目最紧张的部分陷入完全的盲区。\n持续集成完全可以解决这个问题。没有了长期的集成，你就可以完全的消除盲区。在所有的时间点上你都会知道你身处何处，什么可以工作，什么不能工作，你的系统里有什么最大的bug。\nBug—也就是那些讨厌的东西，会摧毁我们的信心，破坏我们的计划和声誉。如果已经发布的软件中有缺陷，用户就会对你很生气。而正在进行的工作中有bug，则会挡住你的道路，会使得接下来的工作变得更加困难。\n持续集成不会避免bug，但是它可以让你非常容易找到并消除 bug。从这个角度看它很像自测代码。如果你引入了一个bug后能很快检测到它，那么就能很容易改正它。因为你只是对系统做了一个很小的改变，你不用往回追溯太远。因为系统的那一部分正是你刚刚工作过的那一部分，它还很清楚的存在于你的记忆里—这使得查找bug很容易。你还可以使用diff debugging，来对系统的当前版本和没有bug的更早的版本作比较。\nBug也是累积的。你的bug越多，消除每一个bug也就越不容易。一定程度上是因为bug互相影响，表现出来的失败可能是很多错误共同叠加的结果—这就导致很难找到每一个错误。这也是心理上的，当有很多bug的时候，人们自然就缺少激情去找到并解决这些bug—这是一种在《Pragmatic Programmer》一书中被称为“破窗效应”的现象。\n因此，使用了持续集成的项目，无论是在生产环境里，还是在开发过程中，其bug的数量将会极大的减少。但是需要强调的是，受益的程度直接取决于你的测试套件的好坏。你应该可以看到，构建一个带来显著差异的测试套件并不是那么困难。当然，通常一个团队真正达到他们可能达成的较低水平的bug程度，需要一定的时间。要达到这个水平意味着需要持续的改善你的工作。\n如果你使用了持续集成，它会消除掉频繁部署的一个最大障碍。对于能够为新特性更快的获得反馈来说，频繁部署是有价值的，因为它可以使你的用户很快用上这些新的特性，而且频繁部署可以使他们（开发团队和用户）在开发周期中更加协作。这将有利于打破客户和开发之间的障碍—我认为该障碍是成功的软件开发中最大的障碍。\n引入持续集成 所以如果你想要尝试下持续集成的话，从哪儿开始呢？上面我提到的所有的实践可以带给你全部的收益，但是你并不需要一开始就把它们都用上。\n这儿其实并没有固定的套路，而是很大程度上依赖于你的配置和团队的现状。但是我们也学到下面的一些经验可以帮助我们把接下来要做的事情搞清楚。\n  第一步就是把构建自动化。把你所有需要用到的东西都放到源码控制系统中，从而你可以用一条指令来构建整个系统。对于很多项目来说，这并不是一件小事——但是它是其他所有的事情的基础。一开始的时候你可能只是偶尔按需构建，或者只是做自动的每夜构建。当还不是持续集成的时候，自动的每夜构建也是一个很好的开始。\n  在你的构建中引入一些自动化测试。尝试着识别出问题最多的部分，并且加入自动化测试以暴露这些问题。需要特别指出，在一个现存的项目上非常快的实现一个真正好的测试套件是很困难的—因为需要时间来构建测试。你必须从某个地方开始—毕竟罗马不是一天建成的。\n  尽量加速提交的构建。构建需要几个小时的持续集成也比没有持续集成要强，但是如果能将这个时间降到10分钟那就太好了。这通常需要对你的代码基础做一些相当大的手术，因为你需要打破对于系统中较慢部分的依赖。\n  如果你开始一个新的项目，那么从一开始就用持续集成。一直关注构建时间，一旦构建速度变慢，超过10分钟的时候，马上采取行动。通过很快的采取行动，你可以在代码变得太大以至于成为主要的痛点之前进行必要的重构。\n  上面所有的这些都可以给我们提供一些帮助。找到一个以前做过持续集成的人来帮助你。和任何新技术一样，当你还不知道最终结果会是什么样子的时候，很难引入该技术。找一个导师来可能会花一些钱，但是如果不这样做，你将不得不付出大量的时间和生产效率。（免责声明/广告—是的，我们ThoughtWorks在该领域提供顾问工作，毕竟我们已经犯过大多数你们将要犯的错误。）\n最后的思考 在 Matt 和我写完这个网站上最初的论文后的几年中，持续集成变成了软件开发的一个主流技术。ThoughtWorks 的项目中很少有不用它的—并且我们可以看到遍布全球的很多人也在使用持续集成。不像一些有争议的极限编程实践一样，我很少听到关于持续集成的负面反馈。\n如果你没有正在使用持续集成，那么我强烈建议你尝试一下。如果你正在使用持续集成，那么这篇文章里的一些想法可以帮助你做得更有效率。在过去的几年里，关于持续集成我们已经学习了很多，我希望依然有更多的东西可以学习和改善。\n延伸阅读 一篇像这样的短文只能覆盖这些基础，但是这是一个很重要的主题，所以我在我的网站上创建了一个导航页面，可以给你更多的信息。\n如果想更多的了解持续集成，我建议看看 Paul Duvall 的书《Continuous Integration: Improving Software Quality and Reducing Risk》（该书获得了 Jolt 大奖—比我想象的还要厉害）。关于更广泛的持续交付过程的更多信息，可以看看 Jez Humble 和 Dave Farley 的书，该书也获得了 Jolt 大奖。\n你也可以在 ThoughtWorks 的网站上找到更多关于持续集成的信息。\n","permalink":"https://devopschina.org/blog/continuous-integration/","tags":["DevOps"],"title":"重温经典：持续集成"},{"categories":["翻译"],"contents":" 社区译者：崔龙波 郭颖 刘海燕 尚君领\n审校：张彪\n原作者：CollabNet VersionOne \u0026amp; Martin Fowler 原文地址：https://resources.collab.net/devops-101/what-is-devops\n 1. DevOps 的起源 DevOps 继承自敏捷软件开发，DevOps 的出现是为了应对敏捷方法所带来的软件开发速度和生产力增长。敏捷文化和敏捷方法在最近十年的发展，呼唤一个更适合端到端软件交付生命周期的整体方法。\n什么是敏捷软件开发？ 敏捷开发是许多迭代和增量软件开发方法的总和。最流行的敏捷方法包括Scrum、看板、规模化敏捷框架(SAFe®)、精益开发和极限编程 (XP)。\n虽然每种敏捷方法都有其独特方法，所有的敏捷方法都有共同的愿景和核心价值观（参见敏捷宣言），都吸纳了迭代和迭代带来的持续反馈，以连续的方式改进和交付软件系统。所有的敏捷方法都包含持续规划、持续测试、持续集成和其他形式对项目和软件本身的持续演进。与传统的瀑布式流程相比，敏捷方法是轻量级的，具有很强的适应性。更为重要的是，敏捷方法都强调给团队赋能，通过协作共同做出快速有效的决策。\n起初，敏捷团队主要由开发人员组成。随着这些敏捷团队在生产软件方面变得更加有效和高效，将质量保证（QA）和开发分为不同的团队显得非常低效。为了提高软件交付速度，敏捷发展到包含 QA，现在敏捷再次发展到包含交付和支持人员，敏捷扩展到从概念到交付的所有阶段。\nDevOps理想通过进一步简化软件变更在构建、验证、部署和交付阶段的移动，扩展了敏捷开发实践，同时授权跨职能团队拥有从设计到生产支持的软件应用程序的全部所有权。\nDevOps是一种IT思想，它鼓励软件开发人员和IT运营人员之间的通信、协作、集成和自动化，以提高交付软件的速度和质量。\nDevOps团队专注于标准化开发环境和自动化交付过程，以提高交付的可预测性、效率、安全性和可维护性。DevOps 的理念为开发人员提供了对生产环境的更多控制和对生产基础设施的更好理解。DevOps 鼓励给团队赋能，赋予团队构建、验证、交付和支持自己的应用的自主权。有了 DevOps, 没什么会扔到墙上。\n2. DevOps 解决的挑战 在开发DevOps应用程序之前，团队需要优先收集业务需求然后再编写代码。代码开发完成后，开发以外的 QA 团队会在一个独立的开发环境中测试程序，如果需求已被实现，当前版本就会交付给运维人员去部署。部署团队进一步细分为网络和数据库这样的筒仓组。每当一个软件程序是“扔到墙上”式的方式交给一个另一个团队时，它就会增加一层障碍。这种模式的问题就在于，当团队分开工作时：\n 开发常常意识不到QA和运维人员可能遇到的影响程序正确运行的障碍。 QA和运维通常关注的是特性，却很少关注软件的业务目的和价值 每个小组都有各自不同的目标，当出现问题时，这些不同的目标将有可能成为导致效率低下和互相指手画脚的原因。  DevOps通过建立跨职能协作团队来应对这些挑战，这些团队共同负责维护运行软件的系统，并准备软件在该系统上运行，同时提高质量反馈和自动化问题。\n常见的Pre-DevOps场景 开发团队的目标是尽可能多的发布新功能，于是他们向QA扔出了一个新的版本。测试人员的目标是尽可能多地发现缺陷。当测试人员将他们的发现提交给开发时，开发人员会变得抵触，并将错误归咎于测试人员使用的测试环境，然而测试人员回复问题不在于他们的测试环境，而在于开发人员的代码。\n最终问题解决了，QA把经过调试的新版本“扔到墙上”式的方式扔给了运维人员。运维团队的目标是限制系统的更改，因为他们担心发布代码会导致系统崩溃。他们的选择就是一键恢复系统。\n运维人员说开发人员给他们提供的版本有问题，开发说在测试环境中一切正常。那么运维人员就开始调试系统直至达到生产稳定。开发人员和测试人员不管生产环境的运行情况，所以当运维人员在彻夜解决生产问题时候他们绝不插手。\n3. DevOps 的目标 要改善所有相关干系人之间的协作关系，从规划到交付，以及交付过程中的自动化，以便于:\n 改善部署频率 缩短产品上市时间 降低新版本的缺陷率 缩短缺陷修复的交付周期 提高恢复服务的平均时间  根据2015年DevOps报告, “高性能IT组织部署的频率提高了30倍，交付周期缩短了200倍; 与此同时，它们的故障减少了60倍，恢复速度提高了168倍.”\n一个常见的Pre-DevOps场景：在新的软件项目开启之前，软件团队（包括开发人员、测试人员、运营和技术支持人员）组织会面。该团队筹划如何构建部署就绪的工作软件。\n开发人员完成开发后，每天都会部署新代码。而自动化测试可以确保代码的质量才可被部署。代码通过所有的自动化测试过程后，便会被部署给少量用户。部署后短期内会对新代码进行监控，以确保其稳定且没有不可预见的缺陷。一旦监控显示它是稳定的，新代码就会扩大范围迁移给其他用户。规划和开发后的大部分步骤无需人工干预即可完成。\n4. 你在 DevOps 坐标中的位置 DevOps 坐标可以帮助我们以不同的角度审视 DevOps。底部的横轴表示人们认为应该最关注 DevOps 的哪一方面，有人坚定地认为 DevOps 应该更多地关注文化而不是工具，而另一些人则倾向于重视工具而非文化。\n纵轴描绘了 DevOps 交付链的三个层级：持续集成、持续交付和持续部署。DevOps 社区将位于 DevOps 坐标右上角的组织称为粉色独角兽，因为极其罕见，这些独角兽以 Netflix、Etsy、Amazon、Pinterest、Flicker、IMVU 和 Google 等公司为代表。在最近的一次调查中，参与者对其所在组织所处的位置进行了投票：\n 左下角: 55% 右下角: 26% 左上角: 14% 右上角: 5%  虽然思想领袖、敏捷教练和博主们经常在右上角描绘 DevOps 愿景，他们却通常会对 DevOps 文化或自动化工具有很强的倾向，并就 DevOps 文化或工具谁更重要进行深奥的辩论。但现实是，没有工具就无法拥有 DevOps；而没有强大的支持型文化，所有的工具也都将无用武之地。\n另一个重要的观点是，上移和右移需要时间，许多组织的第一步将是文化、工具和持续集成的融合，所以如果你读到描述什么是“没做DevOps”的文章，不要气馁，除非你已达成不需任何人为干预就可一路部署到生产环境。\nDevOps 可以是对您的组织有意义的文化、工具和成熟度的混合体，而有意义的事物很可能会随着时间的推移而发展。重要的是，通过改进协作和自动化，不断努力打破软件交付阶段之间的壁垒和瓶颈。在下面的章节中，我们将深入探讨DevOps 坐标的各个方面，以帮助你更好地理解自己适合的位置。\n5. DevOps 的成熟阶段 DevOps 的成熟度有几个关键阶段，以下是你需要了解的一些关键阶段。\n瀑布式开发 在持续集成之前，开发团队将编写三到四个月的代码。然后，这些团队将合并他们的代码准备发布。不同版本的代码会有很大差异和更改，以至于实际的集成步骤可能要花费数月的时间。这种过程非常低效。\n持续集成 持续集成是一种将新开发的代码与要发布的主干代码快速集成的实践。在团队准备发布代码时，持续集成可以节省大量时间。\nDevOps 没有提出这个术语。持续集成是一种源于极限编程方法的敏捷工程实践。这些术语已经存在了一段时间，但是DevOps采用了这个术语是因为要成功地实施持续集成需要自动化。持续集成通常是走向 DevOps 成熟的第一步。\n从DevOps角度来看，持续集成过程包括检入代码，将其编译为可用代码（通常是二进制可执行文件）并运行一些基本的验证测试。\n持续交付 持续交付位于持续集成之上，是持续集成[DevOps阶段2]的扩展。在实施持续交付时，需要添加了额外的自动化和测试，这样才能做到不只是将代码与主干代码频繁合并，而且可以在几乎无需人工干预的情况下就可部署就绪。这是使代码库持续处于部署就绪状态的一种实践。\n持续部署 持续部署，不要与持续交付混淆[DevOps 涅槃]，是持续交付的最高演进。这是一种不需任何人为干预，直接实现生产环境部署的实践。\n实践持续交付的团队不会部署未经测试的代码；新创建的代码在推向生产之前需要先通过自动化测试的验证。代码发布通常先面向一小部分用户，然后有一个自动的反馈循环来监控质量和使用情况，最后才会进一步传播。\n只有极少数公司真正在实践持续部署，典型的公司有 Netflix、Etsy、Amazon、Pinterest、Flicker、IMVU和Google。\n大多数企业并不以 DevOps 涅盘为终极目标，而是专注于不断提升持续交付能力。\n6. DevOps 的价值观 DevOps 非常重视建立合作文化，以及通过自动化的 DevOps 工具提升效率。虽然一些组织和人员认为其中一个比另一个更重要，但现实是要有文化和工具的结合，才会取得成功。对于 DevOps 这两项价值观，需要了解以下内容。\nDevOps 文化 DevOps 文化的特点是增加协作、减少筒仓、分担责任、自治团队、提高质量、重视反馈和提升自动化。因为 DevOps 是敏捷的扩展，许多 DevOps 价值观就是敏捷价值观。\n敏捷方法是一种更整体的软件交付方式。敏捷开发团队通过工作软件来度量进度。产品负责人（PO）、开发人员、测试人员和用户体验（UX）人员为了相同的目标紧密合作。\nDevOps 在敏捷团队中增加了运营思维，或者有运营职责的团队成员。在 DevOps 之前，进度是以工作软件度量的；而 DevOps 则以交付给客户的可工作软件度量进度。\n为了实现这一点，开发人员和运营人员必须打破筒仓、相互协作，分担软件运行系统的维护责任，通过加强质量反馈和自动化交付准备在系统上运行的软件。\nDevOps 工具 DevOps 工具包括配置管理、测试和构建系统、应用部署、版本控制和监控工具。持续集成、持续交付和持续部署需要不同的工具。虽然这三种实践可以使用相同的工具，但随着交付链的推进，会需要更多的工具。\n7. DevOps 文化 敏捷软件开发已经打破了需求分析、测试和开发之间的一些筒仓，但是部署和运维等其他环节还是面临着与软件开发环节相脱节的情况。而DevOps运动旨在消除这些筒仓并且鼓励开发和运维之间的协作。\nDevOps可能由于结合了一些新的运维工具以及建立了敏捷的工程实践而变得很强大，但这并不足以实现DevOps应有的收益。如果你没有正确的文化，那么即使是使用最好的工具，DevOps也仅仅是另外一个时髦的名词而已。\nDevOps文化的首要特征就是加强了开发和运维角色间的协作，为了支持这种协作，需要在团队中以及组织层面分别有一些重要的文化改变。\n责任共享，是DevOps文化中鼓励更加紧密协作的一个方面的具体体现。对于一个开发团队来说，如果一个系统（他们自己开发的）的操作维护被移交给另外一个团队，那么他们很容易就会对其不再关注。如果开发团队在系统的整个生命周期中分担维护该系统的任务，那么他们就能感受运维人员的痛点，并找出简化发布和维护的方法（比如自动部署和加强日志）。他们也可能从监控产品里的系统中获得到观察到的需求。当运维人员分担系统的商业目标责任的时候，他们也能够和开发人员更紧密的合作，以便更好的理解系统的操作需求并且帮助团队满足它。在实践中，协作常常始于开发人员运维意识的增长（比如部署和监控）和运维人员采用新的自动化工具及实践。\n为了支撑责任共享的文化，需要一些组织级的变革。在开发和运维之间不应该有筒仓。对于从开始就一起工作在一个解决方案上的工作方式来说，移交周期和文档不是很好的实践形式。对团队能够有所帮助的是调整资源结构，以使得运维人员更早的融入团队，让开发人员和运维人员坐在一起可以帮助他们一起工作。移交和签字会阻碍人们共享责任并且带来一种抱怨的文化。相反的，开发人员和运维人员应该共同为系统的成败负责。DevOps文化模糊了开发和运维角色之间的界线，并最终消除掉这种角色的区别。当为一个组织引入DevOps的时候，一个常见的反模式是给某个人分配一个“DevOps”角色或者称一个团队为“DevOps团队”，这么做会使得阻碍DevOps文化和实践在更大的组织中传播及采用的筒仓被固化，而这种筒仓本来是DevOps旨在要打破的。\n组织的另外一个有价值的改变是自组织团队。为了让开发和运维人员之间的协作更有效率，需要他们可以不依赖于错综复杂的决策流程而能够自己做决定并实施变革。这需要信任团队，改变风险管理的方式并且创造一个不用害怕失败的安全环境。比如说：一个团队为了部署到测试环境而必须生成变更列表来签字，那么该团队很可能经常延迟。取代手动检查，可以依靠版本控制，因为版本控制也是可依赖并可审计的。可以将版本控制中的改变链接到团队项目管理工具中的表单上。没有了手工签字，团队可以自动化部署并加速他们的测试周期。\nDevOps文化的转变带来的一个效果，是新功能上线到生产环境中变得比以前更容易。这对于将来一些更深入的文化改变是非常必要的”。为确保产品中的改变是可靠的，团队需要重视“在开发过程中内建质量”的价值。这包括跨功能的考虑，比如性能和安全。持续交付，包括自测，就形成了允许我们周期性的、低风险的部署的基础。\n为了持续的改进开发人员和运维人员的协作方式以及改进系统自身，对于团队来说，还需要重视反馈。对于诊断问题和持续改进来说，生产环境监控是一个很有帮助的反馈回路。\n自动化是DevOps运动的基石，促进协作。如测试、配置和部署发布等自动化方式，可以将人们解放出来，以聚焦在其他更有价值的活动上，并且减少人为的失误。自动化带来的一个有益的“副作用”是：自动化脚本和测试可以被用作对于系统来说有用的、并总是及时更新的文档。比如说，通过自动化的服务器配置可以消除跟雪花服务器（没有一台服务器配置是相同的）相关的猜测工作，这意味着开发和运维人员可以同样理解一个服务器的变更是如何配置的了。\n8. DevOps 使用的工具 前文简要论述了 DevOps 使用的一些工具，下面列出需要知晓的一些关键工具和实践。\n源代码库 开发人员使用源代码库签入和修改代码。源代码库管理签入的各个版本的代码，这样开发人员不会覆盖彼此的工作成果。\n源代码控制已有 40 年的历史，至今依然是持续集成的主要组件。流行的源代码管理工具有 Git、Subversion、Cloudforce、Bitbucket 和 TFS。\n构建服务器 构建服务器是把源代码库中的代码编译为可执行代码的自动化工具。流行的工具有 Jenkins、SonarQube 和 Artifactory。\n配置管理 配置管理定义服务器或环境的配置。流行的配置管理工具有 Puppet 和 Chef。\n虚拟基础设施 亚马逊的 Web Services 和微软的 Azure 是典型的虚拟基础设施。虚拟基础设施由销售基础设施或平台即服务 (PaaS) 的云厂商提供。这些基础设施提供 API，以便使用 Puppet 和 Chef 这样的配置管理工具编程创建新机器。\n此外，还有 VMware 的 vCloud 这样的私有云。私有的虚拟基础设施使在自有数据中心的硬件上运行云成为可能。\n虚拟基础设施与自动化工具一起，给实践 DevOps 的组织赋能，配置服务器不再需要任何键盘操作。如果想要测试新开发的代码，可以自动把代码发到云基础设施、构建环境、运行所有测试，而无需人为干预。\n自动化测试 自动化测试由来已久。DevOps 测试关注构建流水线中的自动化测试，以确保对可部署的构建有足够的信心。要做到持续部署，就要能相信在没有任何人工干预的情况下，代码是可部署的。而如果没有全面的自动化测试，就不可能达成持续部署。流行的工具有 Selenium 和 Watir。\n流水线编排 流水线如同一条制造装配线，从开发人员提交完工的代码，一直到代码部署在生产环境，或后期的预生产环境。\n一体化的企业级软件开发和交付 VersionOne VS 整合敏捷应用生命周期管理和 DevOps，在一个平台上提供了整个软件交付流水线的全貌。VersionOne® Continuum™ For DevOps 是企业级的持续交付解决方案，支撑整个软件交付周期变更流程的编排、自动化和可视化。\n9. DevOps 的历史 2007 Patrick Debois 是一名软件开发顾问，他的一个目标是研究 IT 的各个方面。为此，Patrick 在 15 年中历任开发人员、网络专家、系统管理员、测试人员和项目经理等许多不同 IT 职位，以体验一个 IT 组织中的每个角色，获得对 IT 的整体理解。\nPatrick 曾在一个大型数据中心迁移项目中做咨询工作。在这个项目中，他负责测试，所以要与开发人员和运营人员共事很长时间。Patrick 一直为 Dev 和 Ops 的不同工作方式感到困扰，在这次数据中心迁移中，面对管理跨越开发团队和运营团队工作的挑战，他尤为沮丧。\n持续集成在敏捷社区中越来越受欢迎，并使开发人员更接近部署，但是仍然没有任何东西可以完全跨越开发团队和运营团队的鸿沟。Patrick 相信一定会有更好的方式让这两个团队协同工作。\n2008 Andrew Shafer 在敏捷 2008 大会上提交了一个“敏捷基础设施”的临时话题。Patrick Debois 看到这个话题就去参会，然而只有他自己出席。对这个临时话题感兴趣的人少到话题发起人 Andrew 本人都未现身。\n幸运的是，看到有其他人也有兴趣解决开发团队和运营团队协作的挑战，Patrick 热情高涨，找到了 Andrew 安德鲁，俩人决定建立一个名为敏捷系统管理的谷歌讨论组。\n2009 在圣约瑟的 O\u0026rsquo;Reilly Velocity 大会上，Flickr 技术运营高级副总裁 John Allspaw 和 Flickr 工程总监 Paul Hammond 作了著名的演讲，“每天 10 次部署 - Flickr 的开发团队和运营团队协作”。这一演讲为开发团队和运营团队如何有效协作以改善软件部署奠定了基础。\nPatrick Debois 通过视频直播观看了这个在比利时的演讲，并受到启发，在比利时的根特市发起了他自己的会议，DevOpsDays。这次会议聚集了一群积极进取、有前瞻性、努力改善软件部署的精英。可能更重要的是，这群人在推特上用 #DevOpsDays 标签继续讨论。为了节省推特讨论的字符，大家去掉了标签中的 Days，标签就成了 #DevOps。\n2010 第二年，DevOpsDays 在澳大利亚和美国举行。随着时间的推移，越来越多的 DevOpsDays 在世界各地的不同国家和城市举行。面对面的会议激发了越来越多的人对 DevOps 充满热情，直到它成为一场全面的草根运动。\n2011 直到 2011 年，DevOps 运动一直由个人和开源工具推动，很少有分析师或供应商关注。但在 2011 年，这项运动开始成为主流，吸引了 Gartner 公司的 Cameron Haight 和 451 Research 公司的 Jay Lyman 等分析师的注意。大的供应商开始热捧 DevOps。\n2012 到 2012 年，DevOps 很快成了一个流行语，DevOpsDays 继续增长。\n2013 公众对 DevOps 信息的渴望给了几位作者就此主题撰写书籍的灵感。最引入注目的书籍有 Gene Kim, Kevin Behr 和 George Spafford 的《凤凰项目》，Mary Poppendiek 和 Tom Poppendiek 的《精益软件开发》。\n2014 诸如 Target、Nordstrom 和乐高这样的大公司成为第一批引进 DevOps 的公司。\n","permalink":"https://devopschina.org/blog/what-is-devops/","tags":["DevOps"],"title":"什么是 DevOps？DevOps 终极指南"},{"categories":["调查"],"contents":"概述 自敏捷状态调查开始以来，已有超过40,000名敏捷管理人员、实践者和顾问参加了该调查。第14届年度敏捷状态报告为敏捷在企业不同领域的应用以及关于价值流管理提供了深刻的见解。当你查看调查结果时，你可能会发现一些熟悉的趋势，并发现与去年的调查相比有一些值得注意的变化。往下读，深入研究这些数字，发现一些有趣的相关性。\n关于这次调研 第14次年度敏捷状态调查是在2019年8月至12月之间进行的。这次调查由Digital.ai(以前是CollabNet VersionOne)赞助，邀请了来自全球软件开发社区各行各业的个人参加。收集、分析了1121份完整的调查回复，并通过分析将其整理成一份总结报告。Net Research是一家独立的调查咨询公司。只有14%的受访者是CollabNet VersionOne客户，表明受访者的范围和多样性。\n报告目录  点此下载英文原版pdf报告文件 点此下载中文版pdf报告文件  ","permalink":"https://devopschina.org/blog/14th-annual-state-of-agile-report/","tags":["Agril","DevOps"],"title":"第十四届敏捷开发状态报告"},{"categories":["社区"],"contents":"网站团队的长期贡献者们的第一次线上会议。这是该团队的第一次线上见面会。一共有 7 人参加了本次会议。\n参会者  刘征 - 主持人 崔龙波 张彪 韦世滴 吕益行 唐明 李大平  会议时间：2020 年 7 月 7 日， 晚8：30 ~ 9：20\n会议纪要  回顾社区所使用过的代码库和未来的规划  https://gitlab.com/devopschina/ 2019年主要使用代码库，半私有。 https://devopscoach.coding.net/ CODING平台管理私有代码库，同时对接腾讯云虚拟机的部署流程。【再次鸣谢腾讯云为社区赞助的云资源和 CODING 平台 1 年期订阅】 https://github.com/devopschina/ 公开协作代码库。   评审新的工作计划，演示了 CODING 平台发布网站的流程 ，在该平台中评审和解释了’社区官网\u0026rsquo;和‘大会官网’ 相关工作的 Backlog。 回顾了目前遇到的突出的待解决技术问题。 张彪出任网站维护组组长，负责日后网站相关工作的统筹和服务管理。 提出了‘社区贡献’积分项目的开发设想，没有展开需求分析。  首次社区工作会议合影。\n","permalink":"https://devopschina.org/blog/web-team-meeting-1/","tags":["志愿者"],"title":"2020 年第二季度-网站维护团队工作会议"},{"categories":["翻译"],"contents":" 社区译者：Eric Li\n审校：Kalid\n原作者：Eric Harvieux\n原文地址：https://cloud.google.com/blog/products/management-tools/identifying-and-tracking-toil-using-sre-principles\n Google 站点可靠性工程师(SRE)用来验证有效性的关键指标之一就是衡量我们如何利用每一天的时间。我们希望有足够的时间来进行长期性项目的工作,但鉴于我们也负责 Google 服务的持续运营，有时候也需要做一些手工工作。我们的目标是将少于一半的时间花在所谓的“琐事”上。那什么是琐事，怎样才能阻止它干扰工程师的工作速度？我们将在这篇文章中讨论这些问题。\n首先，我们先来定义琐事，在《站点可靠性工程手册》第五章中是这样定义:\n “琐事是一类手工的，可重复的，可自动化的，短效的，缺乏持久价值，并且随着服务增长呈线性增长的工作。”\n 一些琐事的例子包括:\n 处理配额请求； 申请数据库架构更改； 检查非关键监控告警； 从剧本复制粘贴命令。  这些例子都有一个共同点，它们不需要工程师的人工判断，该工作容易但又不会给你很大回报，而且它会打断我们服务扩容和发布新功能的进展。\n接下来谈谈如何带领团队一步一步识别、衡量和消除琐事的过程。\n识别琐事 处理琐事最困难的部分是识别它。如果你没有明确跟踪它，那么团队中可能会发生很多你不了解的工作。琐事通常来自于发给你的一个短信或电子邮件，你勤勉地完成了工作但没有其他人注意到。我们从澳大利亚悉尼的 CRE Jamie Wilkinson 那里听到了一个很好的例子，他分享了他在管理 Google 数据存储服务之一的团队中担任 SRE 的经历。\n杰米(Jamie)的 SRE 团队分散在悉尼和加利福尼亚山景城（Mountain View）之间，两个站点的工作之间存在很大的脱节。悉尼的部门感到沮丧的是，他们依赖于山景城的项目工作从来没有被完成。悉尼的一位工程师走访了山景城的团队，发现那里的团队全天经常被打扰，处理开发人员的临时造访和即时信息。\n尽管定期召开会议讨论紧急事件和项目工作，并且抱怨山景城方面工作过度饱和， 但悉尼的团队还是因为不知道这些请求的上下文帮不上忙。因此，团队决定要求将所有请求作为错误提交。山景城团队也开始接受培训，以便于迅速介 入并为每位客户的紧急问题提供帮助，前后花了三个月的时间才完成文化的变革。之后一旦发生类似情况，他们终于可以在两个站点之间建立人员轮岗以分配负载， 查看有关工作量和所需时间的统计信息，并确定需要修复的重复性问题。\n杰米说:“从中得出的一个结论是，当你开始衡量正确的指标时，你可以向人 们展示正在发生的事情，然后他们会同意您的看法。”“向团队中的每个人显 示收到和完成工单的比率是一个分水岭。”\n当以这种方式跟踪你的工作时，它有助于在你选择的跟踪系统中收集一些轻量级的元数据，例如:\n 它是什么类型的工作(配额更改，生产环境的发布，访问控制列表（ACL）更新等)? 困难程度是多少:容易(\u0026lt;1 小时);中(小时);难(天)(基于人工时间而不是经过的时间)? 谁做的工作?  这些初始数据使得你能评估琐碎工作的影响。但是请记住，此步骤的重点是轻量级，极高的精度在这里几乎没有价值。如果需要捕获许多细节，实际上会给团队带来更多负担，并使他们感到受微观管理。\n成功识别琐事的另一种方法是对团队进行调查。另一个 Google CRE Vivek Rau 定期调查 Google 的整个 SRE 组织，由于不同的 SRE 团队之间琐事的大小和特性不同，因此对整个公司层面的工单指标很难统一进行分析。他每三个月对 SRE 进行一次调查，以找出在整个 Google 占用项目时间的通用问题。可以从以下调查问题开始:\n  在过去的四个星期中，您平均花在琐事上的时间比例是多少?\n 比例0-100%    您对花费在琐事上的时间有多满意?\n 不开心/可以/完全没有问题    排名前三的琐事来源是什么?\n 值班响应/中断/推送/容量/其他/等    您的季度目标中是否有长期的工程项目?\n 是/否    如果是这样，那么在过去四个星期中，您平均花在工程项目上的时间大约占 总时间的一部分?(估计)\n 比例0-100%    在您的团队中，是否存在有些琐事可以通过自动化解决，但却不能这样做，因为琐事占用太多时间以至于无法脱身做长期的工程项目?如果是这样，请在下面说明。\n 开放性回答    衡量琐事 一旦你识别了所有应完成的工作，如何确定工作是否过多?这很简单:定期(我们发现每月或每季度是一个不错的间隔)，估算出在各种类型的工作上花费了多少时间。 在故障单，调查和应急事件响应中查找模式或趋势，并根据花费的总人力时间确定优先级。在 Google SRE 中，我们的目标是将琐事工作的时间保持在每个 SRE 时间的50%以下，并保留其余50%的时间用于工程项目工作。如果估算结果表明我们已经超过了50%的琐事门槛，那么我们会明确地将减少工作量并使工作平衡回到健康状态定为新的目标。\n消除琐事 既然已经确定并衡量了琐事，现在是时候将其最小化了。正如已经提示的那样，解决方案通常是使工作自动化。这并不总是那么简单，目的不应该是消除所有琐事。\n将不经常执行的任务(例如，在新站点部署服务)自动化可能很棘手，因为在这种情况下你再次执行同一任务时，你的步骤或在自动化时所做的假设可能会发生变化。如果你花费大量时间在这种工作上，请考虑如何更改基础体系架构以适应这种可变性。你是否使用基础架构即代码 (IaC) 解决方案来管理系统?可以多次执行该过程而没有负面影响吗?是否有测试来验证执行过程?\n像对待其他生产系统一样对待你的自动化。如果你有 SLO 实践，把一些错误预算用在自动化上来消除琐事。当你的自动化失败时，需要及时做事后检查，并像处理任何面向用户的系统一样对其进行修复。你希望在任何情况下(包括生产事故)都能使用自动化，以使人员能够自由地完成他们擅长的工作。\n如果你的用户已经习惯建立工单以请求帮助，请使用工单系统作为自动化的 API，从而使工作完全自助。\n另外，由于琐事不仅限于技术层面，也体现在是文化上，所以确保只有被分配到的人才需要处理琐事。这个人可以是值班人员，或者是被轮岗处理 “故障单”或“服务中断”的工程师。这样可以保证其余成员的时间来进行项目工作，并强化了一种对琐事公开和负责的文化。\n复杂性和琐事的区别 有时，工程师和领导层会误将技术上或组织中的复杂性看作琐事。他们对人的影响很相似，但复杂性引发的工作没有满足本文一开头对琐事的定义。即琐事通常缺乏长久的价值，而复杂性是让非常有价值的工作变得很费力。\nGoogle SRE Laura Beegle 一直在 Google 内部进行调查，并提出了另一种识别复杂性的方法:尽管设计简单，健壮的系统令人非常满意，但它可能是部署在分布式环境中，被各种不同类型的用户使用，又或随着时间的推移开始提供更多的功能，这些都足以让它变得日渐复杂。我们希望我们的系统随着时间的推移而发展，同时也减少我们所谓的“复杂体验”,任务完成时间或难度与我们期望不吻合而带来的负面感觉。量化系统的主观体验还有另外一个名称:用户体验。在这些情况下，SRE 自己就是用户，通过良好管理系统复杂事务可以带来一些可观测结果，进而带来更好的用户体验。\n解决运维的用户体验是一项具有持久价值的工程工作，因此与琐碎的工作不一样。如果发现复杂性正在威胁系统的可靠性，请采取措施。通过遵循一个不指责的事后分析，或团队调查，你可以识别一些由于复杂性导致意外结果或恢复时间长于预期的情况。\n我们不可避免地需要对系统进行一些手动维护，但是所需的人员数量不应随虚拟机，用户或请求的数量线性增长。工程师都知道使用计算机完成日常任务的好处，但是往往发现自己还是手工完成了很多工作。 通过识别，测量和减少琐事，我们可以降低运营成本，并确保有时间专注于困难而有趣的项目。\n更多关于 SRE 的信息, 请参考《SRE 基础知识》或浏览《SRE》一书.\n","permalink":"https://devopschina.org/blog/identifying-and-tracking-toil-using-sre-principles/","tags":["SRE"],"title":"使用 SRE 原理识别和跟踪琐事"},{"categories":["翻译"],"contents":" 社区译者：周一行\n审校：吕益行\n原作者：Gustavo Franco, Matt Brown\n原文地址：https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started\n 在 Google，站点可靠性工程（SRE）是我们不断定义可靠性目标，衡量这些目标，并根据需要努力改善我们的服务的做法。我们最近指导您浏览了 SRE 工作手册。您可以将这些指导视为 SRE 团队通常会做的事情，并结合团队的成熟度，确定何时团队倾向于执行这些任务。我们相信，许多公司都可以按照该指导来启动和发展新的 SRE 团队。\n从那时起，我们听说人们了解 SRE 在 Google 上通常会做什么，并了解应该在 SRE 成熟度的各个级别上实施哪些最佳实践。我们也从很多人那里听到了您如何定义自己的团队成熟度水平。但是，对于接下来的“SRE 团队的实际组织方式”，直到现在为止，基本上尚未记录在案！\n在这篇文章中，我们将介绍 SRE 团队的不同实现，是如何为实现目标建立界限的。我们描述了我们经历的六个不同的实现，以及我们观察到的最重要的优缺点。请记住，您对 SRE 的实现可以有所不同，这不是详尽的清单。近年来，我们在 Google SRE 组织中看到了所有这些类型的团队（即一组 SRE 团队），除了“Kitchen Sink”类型的团队。随着 SRE 团队积累经验，此处的实现顺序是相当普遍的发展路径。\n在开始实施 SRE 之前 在选择此处讨论的任何实现之前，请与您的团队做一些准备工作。我们建议分配一些人的工程时间，并在公司内找到至少一名兼职的 SRE 相关实践的倡导者。这种类型的初始，非正式形式的组织方式有一些优点和缺点：\n优点：\n 无需组织更改即可轻松开始 SRE 旅程。 使您能够低成本地测试和适应您的环境的 SRE 实践。  缺点：\n 日常工作需求与采用 SRE 实践之间的时间管理。  推荐给：没有规模来采用 SRE 团队专门人员的组织，和/或在广泛采用之前尝试 SRE 实践的组织。\nSRE 团队实施的类型 1. Kitchen Sink，又名“Everything SRE” 这描述了一个 SRE 团队，其中所涵盖的服务或工作流的范围通常是不受限制的。它通常是现有的第一个（或唯一的）SRE 团队，并且可能会像 Google SRE 刚开始时那样自然发展。此后，我们采用了混合模型，包括下面列出的实现。\n优点：\n 假设只有一个团队，SRE 团队之间没有覆盖差距。 易于发现的模式，并在服务和项目之间有相似之处。 SRE 倾向于充当不同开发团队之间的粘合剂，利用不同的软件来创建解决方案。  缺点：\n 通常缺乏 SRE 团队章程，或章程规定公司中的一切都可能在范围之内，冒着使团队超负荷的风险。 随着公司和系统复杂性的增长，这样的团队倾向于从能够对所有事物产生深远的积极影响，转向做出更多浅薄的贡献。有一些方法可以缓解这种现象，而无需完全更改实施，或启动另一个团队（请参阅下面的服务层）。 涉及此类团队的问题可能会对您的整个业务产生负面影响。  推荐给：一家只有几个应用程序和用户流程的公司，在没有专门的 SRE 团队的情况下，采用 SRE 做法和对角色的需求已经超出了可以配备的人员，但是范围很小，以至于无法拥有多个 SRE 团队。\n2. 基础设施 这些团队倾向于专注于幕后工作，这些工作有助于使其他团队的工作更快，更轻松。常见的实现包括维护共享服务（例如 Kubernetes 集群），或维护在“公共云”的提供商，例如，Google Cloud Platform（GCP），之上构建的公共组件（例如，CI/CD，监控，IAM ​​或 VPC 配置）。这不同于从事与产品相关的服务的 SREs，即内部编写的面向客户的代码。\n优点：\n 允许产品开发人员使用 DevOps 实践来维护面向用户的产品，而在整个企业中的实践上没有分歧。 SRE 可以专注于提供高度可靠的基础架构。他们通常将生产标准定义为代码，并努力消除任何尖锐的边缘，以大大简化产品开发人员运行自己的服务的过程。  缺点：\n 根据基础架构的范围，涉及此类团队的问题可能会对您的整个业务产生负面影响，类似于 Kitchen Sink 实施。 缺乏与公司客户的直接联系，可能导致人们将重点放在不一定与客户体验相关的基础架构改进上。 随着公司和系统复杂性的增加，可能需要拆分基础架构团队，因此适用与产品/应用程序团队相关的弊端（请参见下文）。  推荐给：具有多个开发团队的任何公司，因为您可能必须配备基础架构团队（或考虑配备基础架构团队）来定义通用标准和实践。对于大型公司来说，同时拥有基础架构DevOps 团队和 SRE 团队是很常见的。DevOps 团队将专注于客户化 FLOSS，并为应用程序团队编写自己的软件（功能），而 SRE 团队则专注于可靠性。\n3. 工具 仅有工具的 SRE 团队倾向于专注于构建软件，以帮助开发人员评估，维护和提高系统可靠性或SRE工作的任何其他方面，例如，容量规划。\n可以认为工具是基础架构的一部分，因此 SRE 团队的实现是相同的。的确，这两种类型的团队相当相似。实际上，通常与基础架构团队相关联的服务路径上的共享后端相反，工具团队倾向于将更多的精力放在具有面向可靠性功能集的支持和计划系统上。\n副作用是，通常会有更多直接反馈给基础架构 SRE 团队。工具 SRE 团队冒着为业务解决错误问题的风险，因此需要努力始终了解团队解决前线可靠性的实际问题。 基础架构和工具团队的利弊往往相似。此外，对于工具团队：\n缺点：\n 您需要确保工具团队不会无意间变成基础架构团队，反之亦然。 长期辛劳和整体工作量增加的风险很高。这通常包含在由您的业务主管批准建立的团队章程中。  推荐用于：任何需要高度专业化的和可靠性相关的工具公司，而这些工具目前尚无可用的FLOSS或SaaS。\n4. 产品/应用程序 在这种情况下，SRE 团队将努力提高关键应用程序或业务领域的可靠性，但是诸如批处理程序之类的辅助服务的可靠性，是另一个团队的责任，通常情况下，开发人员同时涵盖 dev 和 ops 功能。\n优点：\n 为团队的工作提供明确的重点，并允许从业务优先级到团队努力的地方之间，明确联系起来。  缺点：\n 随着公司和系统复杂性的增长，将需要新的产品/应用程序团队。每个团队的产品重点，可能导致基础架构的重复，或团队之间实践的差异，这样效率低下，并限制了知识共享和流动。  推荐用于：对于这样的公司，作为第二个或第n个团队，以 Kitchen Sink，基础设施或工具团队为起点，并且具有关键的面向用户的应用程序，并且具有很高的可靠性需求，这证明专用的 SREs 的费用相对较高。\n5. 嵌入式 这些 SRE 团队，让 SREs 嵌入了他们的对应的开发团队，通常是每个开发团队一个。嵌入的 SREs 通常与开发人员共享一个办公室，但是嵌入式安排可以是远程的。\n嵌入式 SRE 与开发人员之间的工作关系，往往受到项目或时间的限制。在嵌入式安排期间，SREs 通常是非常操作性的，执行诸如更改代码和服务配置之类的工作。\n优点：\n 使专注的 SRE 专业知识可以导向特定的问题或团队。 可以同步演示 SRE 实践，这可以是一种非常有效的教学方法。  缺点：\n 这可能导致团队之间缺乏标准化，和/或实践中的分歧。 SRE 可能没有机会与同伴花费很多时间来指导他们。  推荐用于：此实现可以很好地启动 SRE 功能，或进一步扩展另一个实现。当您的项目或团队需要一段时间的 SRE 时，这可能是一个很好的模型。这种类型的团队，还可以通过推动采用本方式，来增强工具或基础架构团队的影响力。\n6. 咨询 该实现与上述嵌入式实现非常相似。不同之处在于，咨询 SRE 团队倾向于避免更改客户代码和服务配置。\n咨询 SRE 团队可能会编写代码和配置，以便为自己或开发人员构建和维护工具。如果他们执行后者，则可以说他们是咨询和工具实现的混合体。\n优点：\n 通过与直接更改代码和配置解耦，它可以帮助进一步扩展现有 SRE 组织的积极影响（另请参见下面对可靠性标准和实践的影响）。  缺点：\n 顾问可能缺乏足够的背景来提供有用的建议。 鉴于他们通常不会更改代码和配置，即使他们能够间接产生技术影响，咨询 SRE 团队的常见风险被认为是非操作性的（即几乎不会产生风险）。  推荐给：直到您的公司或复杂性被认为很大，并且当需求超出了其他各种实现的现有 SRE 团队所能提供的支持时，我们才建议您配备一个专门的 SRE 顾问团队。请记住，在您为第一个 SRE 团队配备人员之前，我们建议配备一个或几个兼职顾问（请参见上文）。\nSRE 团队实施的常见修改 我们已经看到了对于上述大多数实现的两个常见修改。\n1. 可靠性标准和实践 SRE 团队还可以充当整个公司的“可靠性标准和实践”小组。\n标准和实践的范围可能有所不同，但是通常涵盖更改生产系统、事件管理、错误预算等的可接受方式和时间。换句话说，尽管这样的 SRE 团队可能不会直接与每个服务或开发团队进行互动，通常是团队在其专业领域内的其他地方，确定可接受的条件。\n我们已经看到以两种不同的方式采用这些标准和实践：\n 影响力主要依靠有机采用，并向团队展示这些标准和实践如何帮助他们实现目标。 任务依赖于组织结构、流程和层次结构来推动可靠性标准和实践的采用。  任务的有效性取决于组织文化，以及 SRE 团队的经验、资历和声誉。任务的方法在其他领域中普遍地采用严格流程的组织中可能是有效的，但是在个人具有高度自治权的组织中，成功的可能性很小。在这两种情况下，即使由经验丰富的人员组成的新团队，也可能比具有通过良好实践获得高可靠性的历史和声誉的团队，更难以建立公司范围的标准。\n我们还观察到软件开发是平衡这些方法的有效工具。在这种情况下，SRE 团队开发一种零配置方法，如果服务或目标团队恰巧使用预先确定的系统，则可以采用一种或多种可靠性标准和实践，并增加零设置成本。一旦他们看到使用该系统可以实现的好处（通常可以节省时间），就会影响开发团队通过提供的工具来采用这些实践。随着采用这样的系统的增加，该方法可以转向针对 SREs 的目标改进，并通过与可靠性相关的一致性测试来设定任务。\n2. 服务层级 无论哪种 SRE 团队模型定义了团队的范围，任何 SRE 团队都有权决定他们与所在区域内的软件和服务的互动深度。当开发团队、应用程序或基础架构的数量超过 SRE 团队能完全支持的能力时，尤其如此。 解决这个挑战的常用方法是提供 SRE 参与的层次。这样做通过在这两个选项之间添加至少一层以上的内容，扩展了“对我们而言尚不存在或尚未被 SRE 看到”和“由 SRE 完全支持”的二元方法。\n二元方法的一个共同特征是，“由 SRE 完全支持”通常是指在一些上线流程后，给定的服务或工作流程由 SRE 和开发人员共同拥有，包括及时响应的职责。\n不幸的是，SRE 团队或任何其他团队，在他们可以完全上线多少服务的方面，往往达到极限。随着架构的多样性和服务复杂性的增加，认知负荷和记忆回忆会很痛苦。\n这是 SRE 分层方法的示例：\n 第0层：零散的咨询工作，没有专门的 SRE 人员。 第1层：项目工作，需要一些专用的 SRE 时间。 第2层：该服务已上线（或上线中）以及时响应，并获得更多的专用 SRE 时间。  这些层的实现细节根据实际的 SRE 实现本身而有所不同。例如，通常不希望咨询和嵌入式 SRE 团队在第2层上提供服务（如及时响应），但可能在第1层提供专门的人员（而不是共享人员）。我们建议定义经 SRE 和开发人员领导批准的服务层级文档。此签署与记录您的团队章程（如上所述）有关但不相同。\n曾经有一个 SRE 团队采用多种实现方式的特征，而不是采用服务层的例子。例如，一个单独的 Kitchen Sink 的 SRE 团队，也可以由两名 SRE 顾问扮演双重角色。\n常见的 SRE 路径 您的 SRE 组织可以按照上面的顺序实施。另一个常见的途径是实施在“开始之前”中所述的内容，然后为一个 Kitchen Sink 的 SRE 团队配备人员，但是在需要成立第二个 SRE 团队时，将基础结构的顺序按产品/应用程序交换。在这种情况下，结果是两个专门的产品/应用程序 SRE 团队。当托管的解决方案，例如，Google Cloud 提供的解决方案，以外的产品/应用程序具有足够的广度，但两个团队之间几乎没有共享基础架构时，这才有意义。\n第三种常见的方法是从“开始之前”过渡到基础架构（或甚至工具）团队，跳过“Kitchen Sink”和产品/应用程序阶段。当应用程序团队有能力并且愿意定义和维护SLO时，这种方法最有意义。\n我们强烈建议您尽早在SRE流程中同时评估“可靠性标准和实践”和“服务层级”，但这只有在您建立了第一个 SRE 团队之后才可行。\n接下来我该怎么办？ 如果您只是开始进行 SRE 练习，我们建议您阅读您有 SRE 团队吗？如何开始和评估您的旅程，然后根据我们上面共享的信息，评估最适合您需求的 SRE 实施。\n如果您领导一个或多个 SRE 团队，建议您以通用的术语描述它们的实现（类似于我们上面讨论团队实现的方式），根据您自己的经验评估优缺点，并确保 SRE 团队的目标和范围是通过团队章程文档定义的。此练习可以帮助您避免过载和过早的重组。\n如果您是 GCP 客户，并希望提出要求CRE 参与，请与您的客户经理联系以申请此计划。当然，SRE是一种可与多种基础架构配合使用的方法，使用 Google Cloud 并不是追求这套工程实践的前提。祝您 SRE 旅途愉快！\n感谢 Adrian Hilton，Betsy Beyer，Christine Cignoli，Jamie Wilkinson，Shylaja Nukala 等对这篇文章的贡献。\n","permalink":"https://devopschina.org/blog/how-sre-teams-are-organized-and-how-to-get-started/","tags":["DevOps","SRE"],"title":"SRE 团队的组织方式以及入门方法"},{"categories":["翻译"],"contents":" 社区译者：张洁\n审校：吕益行\n原作者：Alex Bramley\n原文地址：https://cloud.google.com/blog/products/management-tools/learn-how-to-set-slos-for-an-sre-or-cre-practice\n 一直热衷 CRE Life Lessons 博客系列文章的读者们（我们有几十个这样的人!）能够理解调优的服务级别指示器(SLI)和服务水平目标(SLO)的价值。这些概念是站点可靠性工程(SRE)实践的基本构件。毕竟，在没有可以适当度量可靠性指标的情况下，对于您希望实现的服务可靠性，如何讨论更有意义呢?\n客户可靠性工程(CRE)团队帮助 Google Cloud 的许多客户创建了他们的第一个 SLO，并更好地帮助他们了解其服务的可靠性。我们希望各地的团队都能执行这些原则。我们很高兴地宣布，在 CC-BY 4.0许可下，我们的 SLO 技艺工作室将免费提供所有材料，只要认定 Google 是原始作者，任何人都可以使用或重复使用。在过去的一年中，我们一直邀请世界各地的客户来参加我们的研讨会。从现在开始，任何人都可以实行他们自己的版本，来指导他们的同事、客户或会议与会者为什么所有的服务都需要 SLO。\nSLO 的技艺涵盖了什么 SLO 技艺工作室，向来自开发、运营、产品和业务领域的观众，传授了开发 SLO 的基本元素。研讨会的幻灯片附有一份28页的参与者支持手册，它是参与者解决实际问题的部分参考资料和背景资料。\n在研讨会中，我们基于两个基本的认知，以一个业务案例的方式提出 SLO 的价值。基本认知之一，可靠性是任何服务最重要的特性。基本认知其二，100%的可靠性目标对任何事情来说都是不现实的。这些认知是错误预算(error budget)的概念的基础，即在给定的时间范围内，由接近100%的 SLO 目标所引起的允许错误的非零数量。快速的创新和服务的可靠性之间的紧张关系，在不耗尽错误预算的情况下，尽可能快地推出新特性来解决。\n一旦每个人(希望如此)都相信 SLO 是一件好事，我们将解释，通过生产环境中运行服务产生的大量遥测数据，如何选择好的 SLI，并介绍 SLI 方程，这是我们推荐的通用 SLI 的方法。我们介绍了，设置第一个 SLO 目标的两种替代方法，两种方法取决于不同的考量，并提供了如何随着时间的推移聚合这些目标的建议。我们将介绍一个实际的示例—服务器端基础设施，它支持一个名为 Fang Faction 的虚拟手机游戏—并使用它来演示如何将SLI从一个简单的、通用的规范，细化为一个可以由监控系统测量的具体实现。\n至关重要的是，参与者将这些新获得的知识直接应用到实践中，为 Fang Faction 开发了更多的 SLI 和 SLO。通常，当我们与客户一起组织这个研讨会时，我们会将他们大致分成8个小组，并让他们在90分钟内解决研讨会上的问题。每个小组都配有一名经验丰富的 SRE 志愿者，他会促进讨论，鼓励参与，并保障小组不偏离讨论。\n组织自己的 SLO 工作室! 如果你对这一切感兴趣，你可以从支持手册中获取信息，手册中包含了关于如何组织 SLO 工作室的更多信息。如果你没有一个完整的团队需要培训，你可能会对我们在 Coursera 上《可靠性测量和管理》的课程感兴趣，这是一门更全面、可以自行设定学习进度的课程，深入了解、学习 SLI、SLO 和 error budget 的世界。\n","permalink":"https://devopschina.org/blog/learn-how-to-set-slos-for-an-sre-or-cre-practice/","tags":["SLO","CRE"],"title":"学习和传授服务水平/质量目标的技艺 ---- CRE课程"},{"categories":["翻译"],"contents":" 社区译者：吴林伟\n审校：张彪\n原作者：Aparna Sinha，Sampath Srinivas\n原文地址：https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-engine-features-and-guidance-to-help-lock-down-your-containers/\n 从 漏洞 到 加密劫持，再到更多的加密劫持，在整个2019年都有大量安全事件使容器用户保持警惕。随着Kubernetes被用于管理大多数基于容器的环境（以及越来越多的混合环境），对于Forrester研究人员来说不足为奇，在他们2020年的预测中指出，需要**“在日益混杂的云世界中保护应用程序和数据的安全”**。\n无论您是使用Google Kubernetes Engine还是与Anthos混合使用，我们Google Cloud容器安全团队都想让您的容器被很好的保护，并让您全面了解容器的安全性。在2020年开始之际，这里有一些有关如何保护Kubernetes环境的建议，以及有关GKE最新的功能和资源。\n仅运行你所信任的, 从硬件到服务 我们在2019年看到的许多漏洞都通过另一个过于受信任的组件破坏了容器供应链或特权提升。重要的是，您必须信任自己运行的服务，并在容器中应用纵深防御原则。为了帮助您做到这一点，现在可以普遍使用Shielded GKE节点，并且不久之后即可使用Workload Identity，这是一种将GKE应用程序验证到其他Google Cloud服务的身份的方法，该方法遵循最佳实践的安全原则（比如纵深防御原则）。\n让我们更深入地研究这些功能。\nShielded GKE节点 Shielded GKE节点可确保集群中运行的节点是Google数据中心中经过验证的节点。通过将Shielded VM的概念扩展到GKE节点，Shielded GKE节点从两个方面提高了基准GKE安全性：\n节点操作系统的来源检查：\n可通过密码验证的检查，以确保节点操作系统在Google数据中心的虚拟机上运行。\n增强的rootkit和bootkit保护：\n安全和可衡量的启动，虚拟可信平台模块（vTPM），UEFI固件和完整性监控。\n现在，你在创建新群集或升级现有群集时，可以打开这些“Shielded GKE节点”保护。有关更多信息，请阅读文档。\nWorkload Identity 您的GKE应用程序可能使用其他服务（例如数据仓库）来完成其工作。例如，以“仅运行您所信任的内容”为宗旨，当应用程序与数据仓库进行交互时，该仓库将要求对您的应用程序进行身份验证。从历史上看，这样做的方法与安全性原则不符，它们过于宽松的被授权，如果受到威胁，则有可能产生较大的影响。\nWorkload Identity可帮助您遵循最小特权原则，并通过具有短期凭证的Google托管服务帐户自动进行工作负载身份验证，从而降低影响。在beta版博客和文档中了解有关Workload Identity的更多信息。我们将很快推出Workload Identity的一般可用性。\n增强您对不信任的工作负载的安全性 但是有时候，您不能放心地信任正在运行的服务。例如，一个应用程序可能使用了组织外部产生的代码，或者可能是一个软件即服务（SaaS）应用程序，它接收了来自未知用户的输入。对于这些不受信任的工作负载，工作负载与主机资源之间的第二层隔离是遵循深度防御安全性原则的一部分。为了帮助您做到这一点，我们发布了GKE沙盒的一般可用性。\nGKE沙盒 GKE沙盒使用开源容器运行时gVisor额外隔离一层来运行容器，而无需更改应用程序或与容器进行交互的方式。gVisor使用用户空间内核来拦截和处理系统调用，从而减少了容器与主机之间的直接交互，进而减少了攻击面。但是作为一项托管服，GKE沙盒提取了这些内部信息，使您可以只需一步即可简化多层保护。让我们开始熟悉和使用GKE沙盒。\n提升您的容器安全知识 随着越来越多的公司使用容器和Kubernetes对其应用程序进行现代化改造，决策者和业务领导者需要了解它们如何应用于他们的业务以及如何帮助保证业务安全。\n容器安全的核心概念 《为什么容器安全对您的业务至关重要》是专门为不熟悉容器和Kubernetes的读者而写的，它将带您了解容器安全的核心概念，例如供应链和runtime安全。无论您是自己运行Kubernetes还是通过GKE或Anthos等托管服务，此白皮书都将帮助您了解譬如Kubernetes等开源软件如何响应漏洞以及这对您的组织有什么重要的意义。\n新的GKE多租户最佳实践指南 当租户之间共享一个或多个集群时，多租户通常被实现为节省成本或提高生产力的机制。但是，将集群错误地配置为具有多个租户或相应的计算或存储资源，不仅不会节省的成本，而且还会使暴露的租户容易受到各种攻击。我们刚刚发布了新指南GKE企业多租户最佳实践，它可以指导您设置多租户集群，并着眼于可靠性，安全性和监控。阅读新指南查看相应的Terraform模块，并提高多租户安全性。\n了解Google如何在内部处理云原生安全性 正如业界正在从基于单一应用程序的架构过渡到分布式云原生微服务一样，Google也一直在从基于边界的安全性过渡到云原生安全性。\n在两个新的白皮书中，我们发布了有关内部如何执行此操作的详细信息，包括云原生安全性背后的安全性原则。了解有关BeyondProd（Google的原生云安全模型）的更多信息；关于Borg的二进制授权，它讨论了我们如何确保代码出处保护和代码身份认证。\n让2020年成为您的容器安全年 安全是一个持续的过程。无论您是刚开始使用GKE还是已经使用Anthos在云中运行集群，请随时了解Google的最新容器安全功能，并在集群增强指南中了解如何实施它们。\n","permalink":"https://devopschina.org/blog/-exploring-container-security/","tags":["kubernetes","docker","containers"],"title":"探索容器安全性：运行你所信任的，其它的则隔离"},{"categories":["翻译"],"contents":" 社区译者：张楠\n审校：韦世滴\n原作者：Charles Betz\n原文地址：https://go.forrester.com/blogs/yet-more-devops-trends/\n 我们之前发布了一些2020年的 DevOps 预测，但是囿于篇幅的限制，还有好多很棒的想法没有包含进去。在这里，我们补充一些由 Forrester 持续追踪的 DevOps 在2020年的趋势.\n计划/构建/运行和阶段-关口的模式走到了尽头 几十年以来，我们一直用计划/构建/运行的运营模式来治理和管理 IT，但它不够敏捷。在全新的数字化世界里，在构建和运行之间停下来等着专业人士完成质量控制的方式，根本行不通。德明博士在几十年前就摒弃“检查式质量”的做法，然而直到今天，还有太多的 It 组织在这样做。IT 治理（即便是 COBIT 2019的版本）仍然对计划/构建/运行的模式有强烈的倾向性，这需要改变，逐渐脱离阶段关口控制的方式而转向。\n基于原则、动态控制和自动化的持续治理 然而，治理绝不会消失。它将更加注重指导原则，更多的公司将使用自我修正的动态控制，例如 Numerify 为交付团队设计的变更预测软件，或是 SRE 实践，它把生产（系统和环境）支持交还到交付低质量系统的产品团队手里。最后，自动化平台将包含许多治理：为交付团队提供模板化模式和环境，从而自动化地管理那些偏离了策略遵从性的情况。\n更扁平的组织模式 半自治的产品团队如何生存和发展？一些人试图借助 Teal 和 Holacracy，认为它们更适合这个新世界。这样的团队如何保持对齐？我的观点是，我们将从治理“如何”做转向治理做“什么”。治理将挑战团队去做出和遵守承诺，但将在如何做到这些方面赋予团队实质性的自由。\n心理安全 我看到人类社会对数字系统交付越来越感兴趣，也越来越了解员工体验会直接影响客户体验。继谷歌之后，龙头企业开始把“心理安全”作为一个 KPI（关键绩效指标）来衡量。如果我看到风险管理者将低心理安全分数标记为严重的组织风险，我一点儿不会惊讶！正如我们预测的那样，混沌工程将成为一种控制策略，组织是否会围绕组织文化制定相应的措施？您觉得呢？\n恢复工程 在 SRE 和混沌工程之上，就是恢复工程了。恢复工程结合了从工业工程到人类因素乃至认知心理学等专业学科，但它不是象牙塔。安全专业人士（航空、消防/警察/医疗等）遵循恢复工程的准则和使用其研究成果。数字化社区（Digital）和 DevOps 社区在这次聚会上迟到了，但是像 John Allspaw 这样的专业人士正在这个领域开发新的洞见。（我今天刚刚发现了 AWS 的 Adrian Cockcroft 写的这篇引人入胜而又实用的文章。）寻找对传统IT服务管理和监控普遍适用的“工艺智慧”，将被“恢复工程”更为严格的要求所取代。\n标准化将再度兴起 企业架构师们通常负责通过共享平台和设计方法的重用来实现规模经济。最近他们遭遇了困境，就是越来越多的产品团队自治了。当然，组织仍需在那些无差异化的“承重”层面进行标准化。问题是自由到什么程度呢？开发人员可以选择自己偏爱的云服务提供商吗？不行？那底线在哪里呢？授于开发人员自主权可以带来创新还会让客户高兴,但是也有些反对自主的老生常谈。我们如何才能实事求是地对这些平衡进行更多更好的管理呢？\n总之，这一年一定会很有趣！不要转台，同时跟我们讲讲你看到了什么！\n","permalink":"https://devopschina.org/blog/yet-more-devops-trend-for-2020/","tags":["DevOps"],"title":"对2020年 DevOps 趋势更多的预测"},{"categories":["翻译"],"contents":" 社区译者：陈文峰\n审校：韦世滴\n原作者：Grace Barnott\n(原文地址)：https://www.devopsonline.co.uk/the-top-10-devops-trends-of-2019-the-professionals-prediction/\n 流水线自动化 在可能且实用的地方建立自动化任务是整个 DevOps 的公认趋势。软件自动化管道的概念已经变得无处不在。例如，可以看到自从 GitHub 引入 GitHub 操作以来，持续集成和持续交付(CI/CD)工具的数量持续增长。\n随着自动化的普及，“基础结构即代码”工具的不断兴起。Terraform、AWS Cloud Formation、Azure 资源管理器和 GCP 部署管理器等工具允许在开发过程、CI 管道甚至交付和生产过程中随意对环境进行拉起和删除。这些工具正在不断成熟。\nKubernetes 似乎在2019年，Kubernetes 无处不在。自2015年问世以来，尽管有 Mesos 和 Docker Swarm 等产品的竞争，这个非常受欢迎的容器编配器在 DevOps 社区中占据了最大的份额。像 RedHat 和 VMWare 这样的主要软件供应商都全力支持 Kubernetes。越来越多的软件供应商也在 Kubernetes 上默认交付他们的应用程序。\nKubernetes 的使用仍在增长。虽然该平台还没有证明自己适合所有类型的工作负载，但它背后的动力似乎足够强大，可以支持它一段时间。\n服务网格化 关于实施 Kubernetes 的讨论越来越多地与关于服务网格化的讨论结合在一起。“服务网格化”是一个松散的术语，它涵盖了在一个平台中处理服务到服务通信的任何软件。\n服务网格化可以处理许多标准应用程序任务，这些任务是应用程序团队传统上必须在自己的代码和设置中解决的，比如负载平衡、加密、身份验证、授权和代理。使这些特性可配置并成为应用程序平台的一部分，可以解放开发团队，使他们能够改进代码，而不是在分布式应用程序环境中改进服务管理的标准模式。\n可观察性 DevOps 中的另一个趋势是讨论应用程序中的可观察性。可观察性常常与监控相混淆，但它们是两个截然不同的概念。理解这种差异的一个好方法是将监控看作活动，将可观察性看作系统的属性。可观察性是一个来自现实工程和控制理论的概念。当一个系统的内部状态可以很容易地从它的输出中推断出来时，我们就说这个系统具有可观察性。这在实践中意味着很容易从应用程序的内部状态表示中推断出在任何给定时间发生了什么。随着应用程序在本质上变得更加分布式，确定它的某些部分失败的原因(从而影响整个系统)变得更加困难。\n这就是相关的基数概念(指系统存储的时间序列数据的离散项数)出现的地方。通常，基数越高，系统就越有可能被观察到，因为在尝试排除故障时，您需要查看更多的数据片段。当然，收集的数据仍然需要与系统的潜在故障点相关，并且仍然需要一个心理地图来有效地排除故障。\nDevSecOps 虽然 DevOps 组合词已经成为 IT 讨论的标准部分有一段时间了，但其他新词也开始崭露头角。DevSecOps 就是其中之一。随着团队的目标是从一开始就将安全性“融入”到他们的管道中，而不是在开发完成后才试图将其固定下来，这个概念正在获得越来越多的关注。因此，安全性越来越成为 DevOps、SRE 和开发团队的责任;因此，工具如雨后春笋般出现，帮助他们解决这个问题。\n诸如 InSpec 之类的“法规遵从性”工具已变得越来越流行，因为自动化连续安全性成为组织在同时跟踪众多应用程序，服务器和环境的压力下屈服的优先事项。\n随着应用的激增，容器镜像和其他伪像的自动扫描也已成为常态。Aqua 和 SysDig 等产品在持续的安全领域中争夺市场份额。\n您可能还会听到提及 DevSecNetQAGovOps，因为越来越多的应用程序生命周期都在努力使自己成为自动化管道的一部分。 但是，DevSecOps 仍然是对目前较经典的 DevOps 配对方式的一种重现。\nSRE 的兴起 网站可靠性工程（Site Reliability Engineering）是一门源于 Google 的工程学科（2003年甚至还没有创造出 DevOps 这个词之前），在同名的《网站可靠性工程》中进行了详细描述。Google 放弃了对运行中应用程序的支持和维护的传统方法，因此将运营人员的水平提高到了相当于其工程职能的水平。在此范例中，SRE 工程师的任务是确保实时问题得到监控和解决，有时通过编写新软件来提高可靠性。此外，开发团队还将就结构和返工的可靠性和稳定性提出反馈。 SRE 在 Google 的运营范围内运作，由于基础架构的规模，SRE 可能需要在开发和运营之间进行划分（通常是 DevOps 的反模式）。当平台庞大且需要跨数百个数据中心进行标准化时，很难实现一个团队负责从开发到生产的整个应用程序（更传统的 DevOps 方法）。 与2019年的“DevOps Engineers”相比，DevOps 公司招聘“SRE 工程师”的频率更高。这可能是因为认识到 SRE 所具有的特定工程重点，而非 DevOps 在整个公司范围内。\n人工智能 人们越来越多地猜测人工智能（特别是机器学习）在辅助或扩展 DevOps 实践中所起的作用。尽管诸如 Science Logi 的 S1 之类的产品仍处于应用初期，但它们开始进入市场并获得吸引力。 这些产品使用机器学习来基于先前观察到的或规范的行为来检测应用程序中的异常行为。\n除了传统的监控活动外，AI 还可用于优化测试用例，确定在每个构建中要运行还是不运行。这样可以减少将应用程序投入生产所需的时间，而不会冒系统稳定性的不必要风险。\n从理论上讲，谷歌已经发布了有关使用机器学习算法来预测硬件故障的信息。 随着机器学习变得越来越主流，期望有更多此类产品进入 DevOps 领域。\n无服务器化 自2014年 AWS 推出 AWS Lambda 以来，Serverless 一直是个流行语。此后，随着其他提供商和产品的加入，事情一直在升温。\n“无服务器计算”一词可能令人困惑，部分原因是服务器仍需要在某种程度上参与其中。本质上，它描述了一种情况，其中应用程序的部署者不必关心代码的运行位置。 所谓“无服务器”是指开发人员无需处理服务器。 通常，无服务器应用程序与其底层计算平台紧密结合，因此您需要确保适应这种级别的锁定。\nCI/CD 中的“左移右移” 今年，CI/CD 中的“向左移动”和“较小程度向右移动”的概念越来越受到关注。随着发布周期变得越来越小，“向左移动”意味着通过在发布周期的较早版本中使构建失败而提高效率—不仅是通过标准应用程序测试，而且还有代码检验，QA/ 安全检查以及任何其他可以发出警报的检查 开发人员应尽可能早地解决他们的代码问题。\n“右移”测试在生产（或类似生产）环境中进行。 它旨在在引发监控或用户问题之前将问题暴露在生产中。\n总结 这些只是我们在2019年 DevOps 世界的混乱中所观察到的较值得注意的趋势中的一部分。缩写词“CALMS”(文化、自动化、精益、度量、共享)是构建 DevOps 工具和技术思想的一种很有帮助的方式，从2019年到2020年，本文中的10个 DevOps 趋势无疑是这些原则的例证!\n","permalink":"https://devopschina.org/blog/the-top-10-devops-trends-of-2019-the-professionals-prediction/","tags":["Kubernetes","DevSecOps","SRE","Service Meshes\""],"title":"2019年DevOps的十大趋势——专业人士的预测"},{"categories":["翻译"],"contents":" 译者：熊小龙\n  审校：吕益行\n  原文(作者：Shormistha Chatterjee)：https://www.impactqa.com/8-devops-trends-to-be-aware-of-in-2020\n  自动化将成为主要关注点 将注意力从 CI 流水线转移到 DevOps 装配线 人工智能(AI)的崛起，推动了数据科学的发展 “一切皆为代码”的概念 宣传使用无服务器架构 通过人工智能和数据科学实现自动化 更多的嵌入式安全性 Kubernetes 有了显著的发展  根据一项集体研究表明，DevOps 市场在2017年已达29亿美元，预计到2022年将达到66亿美元。DevOps 已经成为一个关键的焦点，并且已经塑造了软件世界，许多专家预测 DevOps 将成为主流，并将在2020年达到顶峰。\n企业不仅对 DevOps 表现出兴趣，而且逐渐采用与DevOps相关的实践和技术。 根据 Hackernoon 引用 Statista 的文章，从2017年到2018年，DevOps 的采用率增长了7％。DevOps 软件市场预计将从2017年的29亿美元增长到2022年的66亿美元（来源：IDC 的估计）。\nDevOps 预计2019年增长\n图： 显示了“DevOps”在谷歌的趋势，并对其在2019年的预计增长进行了假设。\nDevOps具有以下优点：\n 快速响应修正案 提供极快的速度并使安全安排更加灵活 建立完善的协作与沟通渠道 快速识别代码中的错误或漏洞 团队可以毫不费力地将精力放在其他关键事项上，而不必专注于安全功能  许多企业正在采用 DevOps，与2017年的约10%相比，2018年增长达到了17%（据 Statista 统计）。\n图片来源：Statista\n2020年8个DevOps趋势的预测：\n1. 自动化将成为主要关注点 已经实施 DevOps 的公司已经看到了高效率和更快的部署。当谈到 DevOps 时，我们将更多地讨论 DevOps 自动化。零触摸自动化将是未来的趋势。理解 DevOps 周期的 6C 并在这些阶段之间应用自动化是关键，这将是2020年的主要目标。\n2. 将注意力从 CI 流水线转移到 DevOps 装配线 DevOps 的最终目标是改进交付过程的规划和自动化之间的协作。它不仅仅是关于持续集成(CI)，而是关于 CD(持续交付)。公司投入了额外的精力和时间来理解自动化整个软件开发过程。到2020年，注意力将从持续集成(CI)流水线移到 DevOps 装配线。\n装配线的优势：\n 强大的嵌套可见性 本地集成 通过“一切皆为代码”理念快速上船并扩展规模 具有互操作性的完美 CD(连续交付) 基于团队的商业智能和分析  3. 人工智能(AI)的崛起，推动了数据科学的发展 越来越多的人工智能驱动的应用程序将推动数据科学团队在他们的工作流程中寻找 DevOps 哲学。DevOps 方法有望成为处理自动化流水线、维护和测试生产链中多个部署模型的主要选择。\n随着数据科学和开发团队在开发、部署和管理 AI 和机器学习驱动的应用程序方面更加高效，这将进一步推动数据科学和开发团队的发展。\n4. “一切皆为代码”的概念 我们不能否认，编码已经成为 IT 行业的支柱。理解各种 DevOps 工具和自动化脚本在软件开发中起着至关重要的作用，这将在2020年占据主导地位。这个行业的未来取决于开发人员、测试人员和运维人员的技术能力。\n由于 DevOps 的目的是为了简化交付周期，所以需要引入可以用来提高软件生产周期效率的代码。“一切皆为代码”的思想是 DevOps 的内置实践，它可以出现在 SDLC 中，在 DevOps 趋势2020中掀起一股浪潮。如果软件测试人员不学习编码和编写他们的测试脚本，他们可能会受到影响。\n5. 宣传使用无服务器架构 在无服务器的架构下，DevOps 可以达到顶峰。这不是免费的服务器；然而，有一个负责完整架构的云服务。这种非凡的体系结构允许软件开发人员将精力集中在“应用程序部分”上。BaaS 和 FaaS 是无服务器架构的两个关键方面。通过采用无服务器的体系结构，您可以节省时间、降低成本并确保弹性的工作流程。\n6. 通过人工智能和数据科学实现自动化 2020年的主要目标是零触摸自动化。人工智能和数据科学的不断发展改变了游戏规则。各种各样的应用程序都有人工智能的支持，这促使 DevOps 团队寻求自动化的可能性，从而在他们的工作流中发现前景。\n7. 更多的嵌入式安全性 随着安全漏洞的成倍增长和对公司声誉的不良影响，网络安全已成为企业的当务之急。到2020年，DevOps 将很快包括安全。\n最近我们看到了 DevSecOps 的一个流行趋势。DevSecOps 致力于在应用程序开发生命周期中首先注入安全性，从而减少漏洞并提高商业信誉。\n向 DevSecOps 的转变还将带来软件开发方面的巨大协作。它将确保开发过程保持完美、高效和有效。\n8. Kubernetes 有了显著的发展 事实证明，Kubernetes 已成为增长最快的容器技术。在全球范围内，技术专家和 CIO 们更青睐 Kubernetes，因为它的产品和服务预计将在2020年实现增长。今年，我们看到 Kubernetes 的使用开始腾飞，各种规模的公司都拥抱了运行云本地应用的容器。到2020年，我们将开始看到容器编排软件取代一些旧的 DevOps 功能。\n","permalink":"https://devopschina.org/blog/8-devops-trends-to-be-aware-of-in-2020/","tags":["devops","devops trend","automation","security"],"title":"2020年 DevOps 8大趋势"},{"categories":["翻译"],"contents":" 译者：马杰\n  审校：吕益行\n  原文(作者：Anoop Nain)：https://it.toolbox.com/guest-article/devops-trends-2020-5-best-predictions-of-the-year\n DevOps 已经发生了显著的发展，因为大多数人认为这是一个流行语。DevOps 已成为许多组织的关键焦点，在过去几年中，它一直在重塑企业软件开发解决方案的世界。专家预测DevOps在2020年将达到顶峰。\n在过去几年中，DevOps 的发展已在许多企业中取得了显著进展，并将继续广泛进行。2020 年是领导者在其业务流程中规划和实施 DevOps 的关键时期。大多数高级主管都接受了这样的事实，即 DevOps 的角色正在演变，从在孤立的项目中提供边际效率，到成为创新和颠覆的积极催化剂。\nIDC 进行的一项研究对 2018-2022 年全球 DevOps 软件市场进行了明确预测。根据该研究，DevOps 市场在 2017 年达到 29 亿美元水平，预计 2022 年市场将达到 66 亿美元。\n因此，本文将介绍 2020 年推动 DevOps 的主要趋势的预测-\n趋势 1： DevOps AI 当涉及到以非常高效和省时的方式构建更多构建时，DevOps 自动化是不可替换的。它为 AI 和机器学习创造了一个理想的环境，以发挥重要作用。大量的数据始终允许分析技术检测模式，做出正确的预测，并确保 CI/CD 管道的平稳运行。\n手动测试的过程已经开始成为过去，因为现在 AI 正被用来预测代码如何基于活动和存储库日志工作。实施 AI 可自动执行功能、验收和部署测试，以便组织通过确保持续交付，使软件发布过程更快、更无错误。\n越来越多地使用基础结构作为代码，通过更改代码描述，操作管理器在分配服务器环境和群集时将提供更好的灵活性和管理。DevOps 最好的部分是，人们不必编写代码，因为 AI 将使用大量日志报告来对所需操作进行明智的猜测，并通过自动化服务生成代码。\n趋势2：无服务器架构的使用 使用无服务器体系结构，可以将 DevOps 达到一个新的水平。它实际上不是没有服务器，而是有第三方负责整个体系结构的云服务。这种特殊的体系结构允许开发人员只关注\u0026quot;应用程序部分\u0026rdquo;。FaaS 和 BaaS 是无服务器体系结构的两个关键方面。通过实现无服务器架构，您可以降低成本、节省时间并确保弹性工作流。\n趋势 3：低代码DevOps 即使今天的 DevOps 自动化简化了 CI/CD 的流程，它仍然需要开发人员通过作业规范、YAML 文件和其他通过手动编码完成的密集活动来定义管道的重要部分。\n我们知道 DevOps 主要专注于加快整个过程，我们期望 DevOps 平台能够拿出低代码工具，只需点击即可定义管道。\n这些工具使企业软件开发服务能够广泛使用技术来创建和维护管道、策略和导航图。\n趋势4：从单一服务架构到微服务架构的重大转变 曾有一段时间，整体式架构曾经是每个人的最爱，但现在它已成为\u0026quot;过去的事情\u0026rdquo;。微服务体系结构具有超前的单一架构，原因有几个。单体体系结构是单一单元或统一单元的一种形式，而微服务是指连接的小单元的片段。DevOps 只关注最需要的单元。微服务和 DevOps 是齐头并进的，因为两者都专注于同一件事-运营效率。在节省时间和努力方面，微服务体系结构起着重要的作用。\n亚马逊、Netflix、eBay、Facebook、优步、Groupon、谷歌等组织都在使用微服务架构。\n趋势5：DevSecOps将成为安全的终极盾牌 DevSecOps 已经渗透到整个 IT 领域，尤其是 DevOps 的域。它在 DevOps 流程中教授和鼓励安全优先方法，并将安全措施集成到整个 DevOps 机制中。\nDevOps 具有以下优势： 提供极快的速度，使安全系统更加灵活。\n对变革做出快速响应\n建立更好的协作、沟通和协调的健康渠道\n快速识别代码中的漏洞或 Bug。\n团队成员可以将他们唯一的注意力放在其他重要的事情上，而不是专注于安全功能。\n结束语 无论是提供软件开发服务还是销售商品，DevOps 已经成为任何组织的必然组成部分。对于许多组织来说，DevOps 已经成为一种标准的工作方式。\n这5种预测趋势都表明，在DevOps的宇宙中，未来将有一个激动人心的时刻。\n","permalink":"https://devopschina.org/blog/devops-trends-2020-5-best-predictions-of-the-year/","tags":["DEVOPS","SOFTWARE DEVELOPMENT"],"title":"DevOps 2020年的趋势------5个最佳预测"},{"categories":["翻译"],"contents":" 译者：吴林伟\n  审校：韦世滴\n  原文(作者：KELSIE PALLANCK)：https://devops.com/predictions-2020-infrastructure-and-ops-trends-to-watch-in-2020/\n 我们即将步入新的一年，让我们来看一下将影响我们如何开发和交付软件的八大趋势。\nKubernetes 是的，它很大，也正在变得越来越大。到2020年，企业采用这一领先的容器编排解决方案的步伐只会加快。从 KubeCon 2015（500）到 KubeCon 2019（12,000）的出勤率增加2300％。随着越来越多的公司开始看到 Kubernetes 的灵活性，可伸缩性，自动化，高可用性和可移植性带来的直接财务和运营收益，对这种复杂软件的开发人员和工程专家的需求将相应增加。例如：2019年在 LinkedIn 上 用人单位对 Kubernetes 相关职位搜索一共有16,744个职位空缺。鉴于已经庞大且仍在发展的 Kubernetes 社区，我们还应该看到功能发布的速度和数量都会有所增加。\n微服务（Microservices） 据预测，到2022年，所有应用中的90％将具有微服务架构。对于软件工程团队来说，以越来越短的周期（持续交付）来生产和发布软件的业务增长势在必行，这为微服务（持续交付的理想体系结构）的激增铺平了道路。随着企业在2020年及以后继续加速向云计算的迁移，他们越来越珍视尝试微服务提供的新技术栈带来的灵活性。所有企业都希望优化资源，最大程度地减少停机时间，降低基础架构成本并避免技术或供应商锁定。到2020年，随着从整体迁移的速度加快，微服务架构将继续提供更多以及更好的上面所列的所有的优势。\n服务网格（Service meshes） 微服务的兴起导致服务网格并行快速发展。考虑到当前服务网格（Istio，Linkerd，Consul，Envoy）的整体集成对微服务成功密不可分，这只会加速服务网格的发展。作为旨在使构成应用程序的成千上万种微服务能够相互通信的软件，它已迅速成为必不可少的组件，通过供应商生态系统实现大幅增长。由 IBM，Google 和 Lyft 支持的功能丰富的 Istio 是领先的 Kubernetes 服务网格，并且在2020年没有任何改变的迹象，尤其是考虑到它相对易于设置和运行。如果您的企业开始了从单一服务到微服务的旅程，将很快碰到服务网格相关实践。\n可观察性（Observability） 最近几年，现代分布式系统的复杂性已经超出了原先设计的查看工具能力范畴，整个团队需要更详细的工具来查看。输入可观察性-不受监视。像优秀的直升飞机之父一样，软件工程师，应用程序开发人员，SRE 和 DevOps 团队希望了解并了解他们的系统始终在做什么。仅举几例，LightStep，Datadog 和 Honeycomb 就是准备向迅速增长的构建云本机系统的企业团队提供日志记录，跟踪和指标解决方案的供应商。请密切注意 OpenTelemetry，它是一个开放源代码可观察性框架，同时目前它是 CNCF Sandbox 的成员。\n网站可靠性工程(SRE) 对于这个仍然新兴的领域，面临的巨大挑战之一是，不同规模和工作文化的企业如何找到一种有效的SRE形式。在 Google 上取得成功的经验可能并不能够为在小型科技企业或初创企业中实施SRE提供借鉴。 SRE 的角色以及期望仍然不稳定，不成熟。SRE 持续不断自动化的需求，只会增加到关键的 SRE 和 DevOps 工具案例中 ，例如 Terraform，Ansible 和 Jenkins。思考 Amazon 的 Prime Day 2018亏损高达9900万美元可以清楚了解 SRE 在未来几年中对业务至关重要的重要性。就业市场反映了这一新现实。\n安全（Security） 软件开发生命周期中的向左移动一直在进行。繁琐的后期制作安全性的时代正在迅速消失。 DevSecOps 尽管仍然是一个时髦的名词，但仍然一直存在，为理论上增加了更多的实践和案例。支持软件开发工作流程的自动化应用程序安全性工具机会巨大。\n然后就是隐私。GDPR 于去年5月生效，《加州消费者隐私法案》于2020年1月1日生效。最重要的是，HIPAA 和对安全领域的企业的合规压力已经很大，再加上云安全的巨大挑战。赛门铁克2019年针对云安全威胁的一项调查报告称，云中65％的企业仍未使用多因素身份验证。该调查还指出，赛门铁克云客户中有惊人的85％并未采用最佳安全实践。寻找在此过程中较早趋向于安全考虑的企业的商业机会。\n无服务器（Serverless） 无服务器时代正处于繁荣时期，随着在2014年推出 AWS Lambda 之后，Google 的 Function，Microsoft 的 Azure Functions 和 IBM 的 OpenWhisk 都提供了其无服务器解决方案。在升级旧系统时，希望更多的企业采用无服务器优先的方法，可以看到可观的成本节省和应用程序开发益处。初创企业也将看到削减成本的优势和无服务器带来的敏捷性。无服务器导致的云中应用程序开发和体系结构的变化很难被夸大。利用供应商现在提供的解决方案，开发人员可以很自由的做他们喜欢做的事情：更快地运行代码并向其应用程序添加功能，而不必担心扩展性和可用性。像微服务一样，无服务器的使用将随着整体单一应用时代逐渐消失而急剧增加。\nDevOps 随着云计算的需求以及企业对专业开发运维团队的投入越来越大，DevOps 有望在2020年实现从政策和原则到实际实践的过渡。另外在 DevOps 领域，DevSecOps 对打包,配置部署安全的软件的自动化的需求变得更加紧迫。ML 和 AI 驱动的应用程序已经到来，DevOps 实践将在开发工作流程中扮演重要角色。零接触自动化的目标迫在眉睫，这增加了对清洁数据，组织支持和集成度更高的系统的需求。尽管 AIOps 引起了广泛的关注，但它仍处于起步阶段，它对 IT 运营的好处仍比实际更具理论性，但敬请期待。\n随着我们进入2020年，看到这些趋势的发展将令人兴奋。 DevOps 团队可以期待在任何架构中开发和部署应用程序的方式，并且将继续发展。通过关注 Kubernetes，微服务和其他新技术的最新发展，他们将为将业务带入新的十年做好充分的准备。\n","permalink":"https://devopschina.org/blog/infrastructure-and-ops-trends-to-watch-in-2020/","tags":["Infrastructure","DevOps","Kubernetes","SRE"],"title":"2020 年预测：2020 年值得关注的基础设施和运营趋势"},{"categories":["DevOps"],"contents":"点此下载原版pdf报告文件 关于作者 GENE KIM - IT Revolution创始人、作家、研究员 Gene Kim 是屡获殊荣的首席技术官，研究人员和作家，自1999年以来一直在研究高效技术组织。他是DevOps企业峰会的创始人，他写了六本书籍，包括最近发行的《独角兽项目》。\nDEREK LANGONE - XebiaLabs首席执行官 Derek Langone 是战略型技术领导者，拥有良好的成长和成功记录。除了将XebiaLabs打造为市场领先的公司之外，Derek还带领Progress Software，SmartBear，Quest和Telerik 取得了傲人成果。\nT.J. RANDALL - XebiaLabs客户成功副总裁 T.j. Randall 拥有20多年的应用程序开发经验，并担任过多个高级工程职务。他帮助众多IT专业人员开发了实用、经济高效的DevOps模型，来驱动当今最具创新性的公司。\n1 谨慎地拥抱云。 85% 的企业发现HYBRID CLOUD是他们组织的理想IT模型。\n60% 的企业意识到安全是影响其未来云战略的最大因素。\n云的采用彻底改变了软件交付流程，并且不会很快消失。无论行业或组织规模如何，对于仍希望在下一个十年存在的企业来说，必须充分利用云。并且持续满足业务、信息安全和合规性的需求是企业云化的必要条件。\n2 再谈卓越中心！ 卓越中心正在从审批委员会的角色转变为顾问的角色。 高效能的DevOps组织将专注于实践社区或平台团队，通过这种形式教给组织内其他部门最佳实践以及如何以可复用的方式推动DevOps。\n“许多企业正在建立卓越中心，以帮助他们实现技术进步和高效的转型目标，并尽可能平稳。”\n建设CoE关键举措：\n  大数据分析\n  数字化转型\n  云\n  DevOps\n  人工智能/机器学习\n  3 DevOps即服务。 是的，一个新流行。\nDevOps即服务提供集中的标准化模板，所以每个团队都不仅仅关注自己的事情。 为了效益，组织应该建立一个由两到五人组成的团队（有时称为平台团队）来将DevOps（监控、CI / CD、自动化发布、编排、云）作为内部共享服务进行管理。这也释放了开发人员，让他们将精力集中在解决业务问题上。\n4 让开发人员专注开发。 业务对开发人员的需求还在上升。让开发人员满意不仅是留住顶尖人才的必要条件，而且还与软件交付和组织绩效直接相关。 为了提高工作满意度，领导者必须允许开发人员可以自由地进行软件生产的重要事项，而不是“琐事”和维护。 在此阅读有关开发人员自由的更多信息ZDNet文章.\n“到2020年，美国劳工局估计将有140万个新的开发人员职位空缺，只有40万计算机科学专业的毕业生可以填补这些空缺。”\n5 安全、不可分割。 48% 的开发人员认为安全性很重要，但是他们没有足够的时间来考虑安全性。\n在过去的一年中，DevSecOps 已经成为主流，这意味着安全不再是一种选择或事后的想法。它必须是完整软件交付管道的一部分，而不是在生产环境之前添加。 为了将安全性转移到流程的更前端，很多组织开始实施操作授权 Authority to Operate（ATO）流程，如果代码通过所有自动控制扫描，则开发人员不再需要等待批准就能将其推入生产阶段。\n6 后端也需要爱。 不要忽略后端的运维（例如客户看不到的应用程序和系统）。\n组织经常过于关注面向客户的功能和改进，但是后端系统运维的有效性才使组织能够平稳运行。 领导者应将他们最好的工程师用于这些内部应用程序，而不仅仅是在构建特性功能上。\nQ： “您认为什么是DevOps成功实施最重要的要素？\nA： “前端应用程序交付与后端基础架构、安全性之间的协调一致。IT和安全性不仅仅意味着最新的前端开发工具，也包括人员相关问题。”\n7 了解您的价值。 数据是开发团队成功的重要因素。在2020年，确定如何及时获取数据并使用它来进行决策的方法将非常重要。 我们看到，越来越多的组织利用价值流映射和管理来生成数据，以回答有关软件交付生命周期效率低下以及为客户创造价值需要多长时间的问题。 了解VSM的基础.\n价值流管理使团队能够更好地提高效率，通过：\n 可视化 数据分析 报告 映射  8 失败也是一个选项。 理解如何从失败中恢复是很重要的，因为我们不关心是否将来会出错，而是何时错误将发生。 团队应在软件交付过程中有意地创建故障和问题，以找出成功的检测和恢复策略。\n我们最近的网络研讨会包括了与Forrester的Charles Betz讨论混沌工程的主题。\n9 安全第一。 心理安全-是Gene Kim的《独角兽项目》的五个理想之一，是使优秀团队表现出色的最大因素。 到2020年，优秀领导力的标志将是能够创造一个安全的空间，以非指责的方式谈论失败。\n10 自动化审计。 从一年几次部署到一天部署几次，合规性和审计过程会发生什么变化？ 从完全不同的工具中提取数据和使用屏幕截图记录活动的手工过程不再有效。 组织应该自动化端到端软件交付过程的证据收集和报告，这样团队就不必在构建和发布软件上浪费时间。 探索如何创建监管链软件并只需单击一个按钮，即可满足合规性和治理要求。\n点此下载原版pdf报告文件 ","permalink":"https://devopschina.org/blog/10-tips-for-devops-success-in-2020/","tags":["DevOps","Tips"],"title":"DevOps在2020年取得成功的10个秘诀"},{"categories":["文档"],"contents":" 致敬中国 DevOps 社区！\n谢谢中国 DevOps 社区所有组织者和志愿者的辛苦付出，谢谢各位赞助商的大力支持，谢谢你们举办了多场精彩圆满的社区活动和技术盛会，谢谢你们为DevOps 在中国的推广和落地做出的杰出贡献！\n飞兔做诗一首，谨以此诗献给中国 DevOps 社区，表达衷心的敬意和感谢，为所有社区的小伙伴们点赞，为社区的宣言点赞。 **《良方》****社区中立要开放，响应需求价值创，****勇于创新容万象，追求匠艺高质量，****劳逸结合保安康，求同存异乐谦让，****合作共赢伙伴帮，互利互助共成长。** 版权声明：此诗版权归成长的飞兔所有，未经许可不得转载，侵权必究，谢谢合作。此诗无偿赠与中国 DevOps 社区以表达感激之情。\n飞兔是一位中年程序员，也是一位诗人，今年的他经历了人生低谷，通过努力、读书、学习、参加技术社区的线上线下分享交流会，破茧成蝶，重新找回自我。这首诗是为社区宣言而做，与大家共赏, 同时与大家重温社区宣言。\n 作为有理想的中国DevOps社区志愿者，我们一直身体力行，传播DevOps文化，落地DevOps实践，并帮助他人学习与实践DevOps。与此同时，我们建立了如下价值观：\n  **《社区宣言》**不仅要让社区中立，更要 **保持开放宗旨** 不仅要去响应需求，更要 **创造社区价值** 不仅要有专业技能，更要 **包容百家思想** 不仅要与多方合作，更要 **建立伙伴关系** 也就是说，左项固然值得追求，右项更加不可或缺。\n ©2019，著作权为下述签名者所有 ，此宣言可以任何形式自由地复制， 但其全文必须包含上述申明在内。\n","permalink":"https://devopschina.org/blog/liang_fang/","tags":["DevOps"],"title":"良方"},{"categories":["演讲"],"contents":" 本文内容选自中国DevOps社区年会 · 2019年会，刘超老师分享的《大规模微服务场景下灰度发布与流量染色实践》实录。\n 大家好，我的题目叫《大规模微服务场景下的灰度发布与流量染色实践》。最近微服务很热，与微服务相关的架构、流程、DevOps都很热。\n很多公司，包括传统企业，到互联网公司做交流的时候，会问道，你们互联网公司号称能够加速业务创新、快速迭代，那我们是否也可以引入类似这样的机制。\n我们做微服务，主要分为两个方面，一个是业务方面，另一个是技术方面。最下面是运维部，不过现在我们的运维部已经拓展成云计算，DBA里的数据管理部门，已经发展成大数据，于是就有了技术中台和数据中台，另外还有共享用户中心的业务中台，总体构成了下层的中台部门，在上层业务一定要做微服务化。业务和技术互相合作，做到加速创新的效果。\n有很多人说，我们也上了微服务，但是会发现上微服务以后，看起来很好的东西，为什么用起来一团乱麻。\n我们拜访过很多业界同仁，发现实施微服务之后，有以下痛点：\n服务依赖管理：服务间直接调用，依赖混乱（微服务越来越多，自己理不清楚，不知道上线时会影响谁，上线后谁影响我，到底该什么时候上线，依赖混乱的时候，没办法解决这些问题。）\n服务调用统计：调用记录无迹可寻，调用统计与分析无从谈起\n服务接口规范：环境与接口规范缺失，维护困难\n服务安全管理：安全靠白名单各自为战\n服务治理能力：大量重复代码 实现路由，分流，熔断，降级\n服务接口测试：拆分过程中接口行为不一致，隐藏Bug\n服务灰度发布：上线功能实现灰度借助大量if-else\n服务压力测试：对于峰值压力无历史数据，靠运气\n服务调用链分析：当服务请求缓慢，难以定位问题点\n测试环境治理：测试环境多，难管理，不可能100个容器每组一套\n我们发现大家对微服务有很多误解。比如，一般做微服务的时候，很多人都会问微服务怎么拆，告诉我一个拆的最佳的实践，但是其实，根据我们的实践来讲，微服务不仅仅是微服务拆分，微服务拆分只是十二个要点的其中之一。\n十二个要点分别是：\n  微服务化的基石：持续集成\n  静态资源分离与接入层设计\n  应用层设计之无状态化与容器化\n  应用层设计之服务的拆分，发现与编排\n  性能优化之数据库设计与横向扩展\n  性能优化之缓存的设计与横向扩展\n  性能优化之消息队列与异步化设计\n  服务的熔断，降级，限流设计\n  配置中心的设计与实践\n  统一日志中心的设计与实践\n  全链路应用监控实践\n  服务的全链路压测实践\n  我们建议，先把前三个基础打好，再进行拆分，而不是什么技术、平台、工具都没有，直接把自己的传统应用拆得七零八落。**同时，值得再强调的是第一条，微服务化的基石：持续集成。微服务绝不是让大家关起门来用三个月的时间拆出来，就直接上线。而是应该不断地集成、迭代，是渐进式的模式。**另外，微服务也不仅仅是个技术问题，它还涉及到IT架构、应用架构、组织架构的改变。\n接下来给大家讲一下网易微服务和DevOps的实践过程。\n我们整个DevOps，也是经历了几个过程。第一个和大家都一样，当服务比较少的时候，开始手工化的方式，后来手工不行了就变成了脚本化的方式，再后来因为开源有很多的工具可以用，变成了工具，而后变成一个平台，最后变成一个统一的DevOps的平台。\n首先，第一个阶段就是手工化。可能很多企业一开始都会存在这样的阶段，开发和运维之间的隔阂比较严重，老死不相往来。开发负责写代码，线上的运维、发布，以及SLA的保障，都是运维进行管理的。由于服务相对比较少，用物理机部署，基本上是一个单机应用加一个Oracle就可以搞定。\n后来，随着业务的发展，服务越来越多。这个模式和原来还是没有变，开发和运维部的隔阂依旧存在。但是，运维发现接的需求越来越多，需要部署越来越多，需要一个环境隔离的方式，因此一般会上一个虚拟化系统，业内主流是用Vmware。这时候的部署方式一般是，Oracle部署在物理机上，其他业务系统都是部署在VMware上。部署东西多了，运维开始使用批量脚本试图解放人力，这属于第二个阶段-脚本化的阶段。虚拟化带来很多的优点，比如，粒度灵活，隔离性得到一定保证，不会在一台服务器上部署很多东西。\n但是这个阶段也有非常多的问题。比如说发布脚本、逻辑相对复杂，时间长了以后，逻辑是难以掌握的。而且，如果你想把一个脚本交给另外一个人，也很难交代清楚。\n另外，并且脚本多样，不成体系，难以维护。线上系统会有Bug，其实发布脚本也会有Bug。\n虚拟机大量地依赖于人工的调度，需要运维人员非常清楚，要部署在什么地方。另外VMware还有一个问题，它使用共享存储，会限制整个集群的规模，因为此时的应用不多，这个程度的规模还可以接受。\n线上的高可用性，业务层的开发人员不会做任何事情，他认为是线上一旦出事，应该由运维集中处理，迫使运维服务的发布人员依赖虚拟化机制，来提供高可用机制。我们都知道VMware有非常著名的简化运维的高可用机制，比如FT、HA、DR等类似的机制。如果我们是从IT层来做高可用，有一个缺点，作为基础设施层来讲，它看上层没有任何的区别，所以没有办法区分业务优先级。比如说FT的模式，跑CPU指令，它不知道这是最核心支付的指令、还是日志的指令，再如数据中心之间的同步，存储层是无法区分交易数据和日志数据的。\n另外网络、虚拟化、存储等基础设施，没有抽象化的概念，复杂度非常高，开发接不了这个工作，必须依赖运维，就要审批。由统一的一帮人来做，而且他们要考证书，比如，网络要有思科的证书，虚拟化要有VMware的证书，要特别专业才能做这件事情，因此会极大地降低迭代速度。业务方无论做什么事，都要走审批，运维部的人根本忙不过来，这是第二阶段的问题。\n后来是怎么改变了这个问题？首先是业务层，业务层接的需求越来越复杂，迭代速度要求越来越快，这个时候单体应用跟不上了，需要进入服务化的架构，工程要拆分，要开始基本的注册发现，要实现自己的RPC。\n应用层的改进会带来应用层的问题。比如，服务雪崩的问题。大量的请求堆积，一个进程慢了，把整个链路也都变慢了，所有人都在等着它缓过来。我们要进行熔断，快速尝试另外的服务。原来依赖很多内网负载均衡以及硬件负载均衡的维护代价比较大，一旦出现任何问题，就会引来抖动的问题。所以相应的要有快速恢复、快速熔断的机制，一旦发现错误以后，我们要能够尽快的重试。\n以上就是应用层的问题，经过了一段时间的解决，又引入了新的问题。**我把它称为“云原生怪圈”，应用向云原生的（Cloud Native）。**它包含两个层次，第一个层次是应用层的服务数目会增多。第二个层次是资源层申请速度的灵活性会相对增加，这两个层次形成了一个圈。每家公司可能都存在这个圈，无论是从哪个起点开始，这个圈都可能会被激活。\n一个起点是，很多公司的上面是单体应用，但下面先采购了容器，资源申请灵活性大幅度提高了。一旦灵活性提高了以后，会给应用层释放很多动力。原来申请一百个机器需要一个星期的审批流程，这时能不拆分就不拆分。而现在有了容器，他会认为我有了这么好的工具，我可以进行拆分了，反正不费劲，任何一个小部门创建一个小的环境都不费劲。\n另外一个起点，先是应用层服务数目增多，给资源层越来越大的压力，然后会使得你原来七八点下班，现在变成十点多下班，然后十二点下班，压力越来越大，就会想办法增加资源层的灵活性。这个圈在整个DevOps的过程中会一直产生的。\n微服务化了以后，我们会发现存在以下几个现象。\n第一个是服务器的机型非常的碎片化，一开始采购机器的时候，有大规格、小规格的，硬盘比例各不一致，导致服务器非常难以管理，也无法进行批量化的安装。\n第二是很多的进程，不管是虚拟化以后，还是不虚拟化，在不在一台机器上，QoS无法保证。\n第三是测试环境的需求量大大增加，下层的基础设施根本忙不过来。\n接下来进入到云计算的平台。有很多人不理解云计算和虚拟化都是运用了虚拟化的技术，两者之间到底有什么不同。其实云计算带来了非常大的不同，甚至是本质上的不同。如果你们内部上了一个云平台，或者上了公有云，但是你没有感受到资源申请的灵活性，那肯定是有些姿势用得不对。\n这里，**我总结了一下云计算带来的改变，主要有三大方面，分别是统一接口、抽象概念，租户自助。**正是因为这三大方面，使开发和运维不像原来那样，有那么深的隔阂，而是开始逐渐互相靠近，开发部或者业务部开始进行一定的自助。\nOpenStack实现接口统一，大部分部署工具支持其接口，可基于开源工具实现发布的工具化和平台化\nFlavor抽象资源配比（4G 8G 计算优化型，网络优化型，存储优化型），统一硬件配置，提升利用率，硬件上线效率提升\n自动调度代替人工调度，区域可用区抽象对机房机架交换机的感知\n云提供租户概念，有账号子账号体系，有quota，可以让租户在管理员许可的范围内自助操作，加快环境部署速度\nVPC屏蔽物理网络复杂性，冲突问题和安全问题，使得租户可自行配置网络\n基于虚拟机分层镜像发布和回滚机制，构建发布平台，可实现大规模批量部署和弹性伸缩\n基于虚拟机的PaaS托管中间件，简化租户创建，运维，调优中间件的难度\n发布平台提供基于虚拟机镜像+PaaS中间件的统一编排\n要求业务对于高可用性设计要在应用层完成\n在这个阶段，要实现微服务框架与开源技术栈的统一。一开始微服务做的比较混乱，有用Spring Cloud，有用Dubbo的，需要一个统一的开源技术栈。另外，还要构建一个持续集成的平台，通过Agent和虚拟镜像部署软件包。\n统一微服务框架之前，我们情况是这样的，一开始用服务注册服务发现，还是比较简单的。后来发现，我们还需要分流、需要降级、配置中心、认证鉴权、监控统计等，在业务代码之外加的越来越多，大家的代码写得到处都是，而且依赖于不同人的水平不一样，有的人写得好，有的人写得差，这就是一个当时遇到的问题。\n后来我们就把它抽象成为了一个Agent，这个Agent在程序启动的过程中，通过jar直接带起来，使得统一的服务框架组件在Agent里面实现，并且提供统一的界面进行配置，这样业务方可以只写业务代码，基本上就搞定了这件事。\n这样就形成了一个统一的微服务治理平台，并且后期会和service mesh做一定的融合。\n因此解决了这些问题：\n应用减负：使用Agent和Sidecar技术，对应用无成本增强。\n开发减负：以微服务治理框架为设计目标、大幅减少重复框架代码、避免重复造轮子。\n版本控制：统一组件版本配置，避免隐性问题。\n兼容性：兼容的HTTP、RPC调用，兼容非java应用。\n服务治理：根据业务线场景选择治理支持方法级别治理粒度。\n高性能：更低的性能损耗，并提供更细粒度的服务治理。\n这时就有了发布平台。我们会把包放统一的对象存储上，通过Agent以镜像的方式进行下发。\n这是我们的成果，内部都在用这款基于虚拟镜像的发布平台。\n接下来又引入了新的问题，比如难以发现故障点、要引入故障注入服务，API版本混乱，这时需要引入API网关。\n基于虚拟镜像的发布也很混乱，因为部署的应用越来越多，我们发现虚拟镜像的模板越来越多，会出现上千个无法复用的模板，好像每个小组织都有自己的一个东西，毕竟它还不是一个标准，所以接下来我们就拥抱了容器的标准。并且Auto Scaling原来是基于虚拟镜像的，现在使用Kubernetes来做，同时实现了分布式事务。\n到了这个阶段，中间加了Kubernetes这一层。这里的更新包括，OpenStack可以做物理机的下发，Kubernetes作为统一的对接资源的编排平台，无论是Vmware上，还是KVM机器上，还是物理机上，公有云上，上面都可以有Kubernetes统一平台。这个时候只需要对Kubernetes下发一个编排，就可以实现跨多个地方进行部署。\n在基于虚拟机的运行环境和PaaS中间件之外，基于Kubernetes也可以有自己的容器镜像和运行环境，以及基于容器镜像PaaS中间件。发布平台原来是对接API的，现在有了Kubernetes以后，它可以非常平滑的通过统一的平台切换到Kubernetes上，所以，做一个发布平台，后面的对接还是比较标准的。\n应用层也会越来越多，比如说有基于容器镜像的弹性伸缩，服务网格，分布式事务，故障注入等。\n有了Kubernetes以后，就进入了Dev和Ops的融合阶段。这时我们发现，当服务数目再增多的时候，运维的压力也更大，如果所有的东西都要运维来做，其实是实现不了的。因此，我们建议环境交付提前，比如说一个容器镜像里面的子环境让开发自己去把控。他知道自己改了哪些内容、哪些配置，不需要通过文档的方式交给运维来做。容器镜像还可以做一个很好的事，它是非常好的中介，是一个标准，不论在那儿都可以，所以就产生了左边的太极图。运维会帮开发部做一些事情，开发帮运维做一些事情，这个时候进入了开发和运维融合的机制。\n因为容器有非常好的分层的机制，如果开发不想写，可以让开发写大部分的基础环境。\n另外一个建议叫不可改变的基础设施。当规模大了以后，任何一个节点出现了问题，都很难排查，所以我们建议对任何环境的修改，都要在代码的级别上修改。在部署平台之前，代码是代码，配置是代码，单实例运行环境Dockerfile是代码，多实例的运行环境编排文件也是代码。\n持续交付流水线，是以Master和线上对应的，自己分支开发的模式。按需自动化构建及部署，线上环境还是需要人工触发的，但基本上是通过流水线代码处理的方式来做的。\n容器化带来的另外一个问题，就是“云原生怪圈”再次起作用。服务规模越来越大，增加速度越来越快，需求指数性增加，大家都需要一个环境。比如一个集群一千个容器，如果三个小组各开发一个项目，想并行开发，每个人都需要一个环境，一下子需要三千个容器。这时候就需要中间件的灰度发布和流量染色的能力。\n在最外层的网关上，可以做两个环境之间流量的分发，以及在微服务的Agent里面也可以做一个分发。最终，我们会有一个基准环境，就是Master对应的环境。\n两个小组，一组开发了五个服务，另外一组开发了六个服务，他们部署的时候不需要一千个全部布一遍，只需要布五个，布六个。在请求调用的时候，从这五个里面互相调，不在这五个里面，在基准环境调，另外六个也是。这样就把三千个变成一千零十几个，环境大幅度减少。\n这个时候环境的合并怎么办？环境合并和代码合并逻辑一致，统一在发布平台管理，谁后合并谁负责Merge。这是我们的一个效果，我们节省了非常多的机器。\n有了流量染色功能，就可以做线上的灰度发布。这里我们会有几个环境，一个是预发类的环境，一个是小流量环境，还有一个主流的环境，测试的时候是可以进行染色。\n我们以一天的整个开发周期举例子，每天早上初始化预发环境和小流量环境＞＞开启引流，进入持续发布周期＞＞代码发布到预发环境进行回归，预发环境为单节点部署＞＞预发通过后发布到小流量环境，小流量环境三节点部署，滚动发布＞＞小流量环境，开发测试及时跟进，观察异常情况，一旦碰到问题，第一时间关闭流量入口。相关问题定位debug可以在预发环境上进行＞＞所有发布到小流量环境的版本合集，通过一个晚高峰的检测后，发布到线上环境。第二天同样是做此循环，每天都是这样的发布模式。\n有了流量染色以后，还可以得到单元化和多机房的染色。如果我们做高可用，至少需要两个机房，那么就存在一个问题，当一个机房完全挂了怎么办？微服务框架可以把它引流到另外一个机房。服务请求之后，还应该回来，因为应该本机房优先，毕竟本机房的容量大得多。所以我们建议整个部署模式，总分总的部署模式。\n首先第一个总，要有统一的发布平台，无论发布到哪个Kubernetes，都应该通过一个平台。其次，你应该有一个多Kubernetes统一的管理，有多个机房，就有多个Kubernetes，我们并不建议跨机房。然后，我们建议应用层要有统一的视图，即使Kubernetes出现了问题，应用层可以把流量切到另外一个环境。就是这样一个总分总的模式。\n另外Kubernetes也面临升级的问题，它更新比较快，经常升级。虽然业界有各种平滑的最佳实践，但是很难保证它升级的时候不出事。一旦Kubernetes出现状况，你也不想停里面的应用，可以采用分流的方式。\n最终形成了云原生架构的技术栈，包括CICD、测试平台、容器平台、APM、分布式事务、微服务框架、API网关一栈式工具链。\n作者 刘 超\n网易\n杭州研究院\n云计算技术部首席架构师\n长期致力于云计算开源技术的分享，布道和落地，将网易内部最佳实践服务客户与行业。 曾出版《Lucene应用开发解密》，极客时间专栏《趣谈网络协议》《趣谈操作系统》。\n","permalink":"https://devopschina.org/blog/grayscale-publishing-and-flow-dyeing-in-large-scale-microservice-scenarios/","tags":["微服务","灰度发布","流量染色"],"title":"大规模微服务场景下灰度发布与流量染色实践"},{"categories":["演讲"],"contents":" 本文内容选自中国 DevOps 社区年会 · 2019 年会，华为云孙超老师分享的《华为云 DevCloud 在大规模团队 Git 协作的探索》实录。\n 大家好！我是来自刚才熊节老师吐槽过的华为公司，但是我相信熊节老师如果现在去华为的话，应该可以看到华为的流程已经是越来越标准化了，尤其是刚才熊节老师的说需求管理这一块，现在我们去看一下的话，应该是比当初看到华为是不一样的了。我今天的主题大概在今年 10 月份在上海的 QCon 分享过一次，当时是有 45 分钟的时间，但是我今天的时间只有 15 分钟，所以按照乔梁老师说的，我今天要用3倍的速度来完成这个 PPT 的分享。\n华为这几年承受了很多外界的压力，尤其像今年一开始某国就开了对华为展开了各种攻势，部分国家或地区也会以华为的产品可能存在安全问题为由，禁用华为产品。那么华为的产品确实是很多，包括路由器、交换机、芯片、手机、数据库、服务器、云产品等等，我们的产品很多，对应的源码也很多，要能够在这些国家和地区进行产品销售，那么我们要证明我们的产品是可信的，是安全的。如何证明我们的产品是可信的？我们就要证明我们的产品通过同样的发布过程能够获取到同样的产品版本，也就是从源代码下载这一步开始，到后面所有的编译打包，包括发布的整个过程，都是有迹可寻的，都是可见和可重现的。\n今天就讲一下在这个背景下，华为在大规模团队的 Git 协作上的一些探索。首先自我介绍一下，我是 2015 年入职华为，在华为入职之后一直是在代码托管领域工作。华为内部的代码托管平台叫 iSource，是 DevCloud 旗下 CodeHub 代码平台的内部版本，我目前担任 CodeHub 的 committer。\n首先大家可以思考一下这三个问题。上面两个问题可能是大家经常会遇到的，第一个是当你们的产品或者你们的项目涉及到 2 个及以上仓库的时候，如何做到代码库相互之间版本的关联？第二个，当有多个人同时在修改多个仓库的时候，如何管理这些这些仓库的分支与 Merge Request ? 最后一个问题其实就是华为很多产品在最初切换 Git 代码库的时候面对的一个问题，我们有的产品部门有几千个开发人员，同时要修改几百个仓库，并且同时开发着几百个特性，这个对于我们代码库的管理来讲其实是很棘手的。下面我会用10分钟的时间，说明一下我们在这类问题上的探索和关键的实践。\n首先我们看一下现在华为内部 iSource 代码平台的规模，现在华为的正式员工包括合作方员工加起来已经注册有 20 多万人，我们的日活用户大概 2 万多。现在所有的代码仓库加起来大概是 60 万多。\n然后大部分项目的规模是特别大的，好多产品部门下面会有几百个代码仓库，然后这些仓库的授权是特别细的，并且耦合非常紧密，特性分支特别多。另外我们发现有些仓库特别大，能达到 10 多个 G。华为的开发团队多数是跨网络分区的，比如说华为国内的研究所有深圳、北京、上海、杭州等，很多团队在开发的过程中，下载的仓库都要跨很多网络分区。我们仓库的构建频率非常高，每天可能要构建几百万次，在高峰期的下载频率能够达到 1 万次每秒。每天的代码下载量，我们统计过最多有 60TB 多，开发人员每天上传的代码量大概 100 GB。我们后台统计的 RPC 请求 6000 W/天，然后 Git 操作次数，例如上传下载大概是 640W 次/天。\n刚才说的这个数据大家可以在知乎上找到相关的文章。在知乎上有一篇文章是《如何看待华为的 1100 亿行代码》，大家如果感兴趣的话可以去搜一下。\n最开始华为内部转型使用 Git 是在 2014 年，大部分产品的代码仓库开始是托管在 SVN 上的，那我们用Git来进行切换，由于 SVN 和 Git 之间的特性的差异，我们就必须要对 SVN 仓库进行分解。我们面临的第一个问题就是多仓库的关联问题，我们一个产品线的仓库，会从 SVN 分出来几百个仓库，最开始我们使用的仓库关联工具是 Git 的 submodule。这个工具我们发现有三个问题。\n第一个就是 submodule 要使用 gitlink 这么一个文件来关联仓库，但是这种关联的方式会导致子仓库修改的时候，都要连带主仓库一起提交。有时候多个项目组同时修改同一个子仓库会产生冲突。之前 有一个 CMO 同事跟我说，他一天的时间有半天的时间在解决冲突，这个问题是挺严重的；另外一个就是 submodule 它是使用 .gitmodules 文件完成仓库和代码目录的关联。使用这个文件，我们要用到 submodule 的一些命令，说实话这个命令使用起来是非常复杂的，好多使用 Git 很多年的一些同事，每次使用这些命令的时候都要去重新阅读，翻一下手册；还有一个就是我们在下载的时候，子仓库只能等到主仓库下载完之后，才能进行后续的下载，非常影响仓库的下载效率。\n另外一个问题是，最开始我们的仓库是使用 fork 模式来进行代码提交，这个是经典的分布式的开发模式。我们的产品某个仓库开始会有一个主线仓库，然后每个子开发部门会 fork 出自己的仓库，再到下面的每一个项目组也进行 fork，然后项目级下每个开发人员再 fork 一次，提到代码的时候我们的方向是反过来的。这个时候有一个问题，当这个 fork 仓库的容量非常多的时候，你的仓库管理就会产生失控的现象，fork 出去的仓库，可以自行改 hooks 的规则，包括人员的一些权限。经常遇到某个 fork 仓库修改了规则，合并了一些提交，最终修改提交到这个主仓库的时候，才发现代码可能是有问题，已经不不符合主仓库的规则要求。那我们看一下github，你使用 fork 仓库创建的 Pull Requset 结束后，通常会建议你去删除 fork 仓库。\n再有一个，fork 会引入另外一个问题。就是跟上游仓库进行同步实际上可能会比较困难，同步的方式大家可以看一下左边这个示例，我们可以通过命令行进行同步，这个过程中通常会遇到各种各样的冲突，解决起来可能会非常复杂。有些代码平台在页面上提供了反向 Merge Request 的功能，但是如果遇到冲突的情况，有时候还是要回到命令行来解决。当然如果你有 100 多个仓库要管理的时候，你肯定要 fork 100 多个仓库，这个同步过程是非常令人厌烦的一个过程。那如果我们不使用 fork 仓库，我们使用分支呢，也会遇到一些问题。比如因为分支全局可见，管理起来会非常混乱，然后分支特别多的话，后台就会容易有过多的分散引用，导致仓库下载非常慢。\n还有就是 fork 派生容易导致磁盘消耗特别快，一般仓库跟刚刚 fork 出来的时候，它的存储是处于最优的情况。当你的派生仓使用了一段时间之后，它的这个文件句柄链接就会发生转移，最终会产生冗余的一些内容。华为在 2016 年发现一个仓库派生了 2000 多次，然后我们做了一次 GC，花了 2 天时间，释放了将近1TB的磁盘空间，所以 fork 也是我们希望解决的一个问题。\n最终我们是希望不使用 submodule，不使用 fork 来提交代码，然后我们也不希望仓库产生那么多的开发分支。\n华为内部做过很多架构上还有用户界面上的优化，最终影响最大的就是对标 Gerrit 平台，我们实现了叫做 OMEGA 的开发模式。OMEGA 是一站式多用途的 Git 协议的简写，是我们基于 Gitlab 的社区版本，进行改造的一种开发模式。\n那么可以看一下 OMEGA 这种开发模式的特点，在代码合并上我们首先不需要 fork，而是通过客户端工具直接把修改推送到代码平台上，产生 Merge Request。还有使用一个叫做 manifest 的清单文件来维护仓库关系，不再使用 submodule 来实现版本关联了。OMEGA 有一个客户端叫做 git-mm，mm 是多模块的意思。\n为什么我们不用 Gerrit？有三个主要的原因，一个是 Gerrit 它的项目管理是碎片化的，不太适合华为的产品仓库场景，同时授权方面也会有跨服务器的问题。最后一个是我们可能希望在华为代码平台上有更多的社交化的属性，因此 OMEGA 是基于gitlab的社区版本进行了二次开发。\n那我们现在说一下 OMEGA，刚才说的这个开发模式，看起来是什么样子呢 ？首先我们在代码平台上会有一个 xml 清单文件，来描述子仓库的关系。\n这个xml文件的第三行的 remote 是代表我们代码仓库服务器的地址，下面有 project 节点列表，左边红色的内容是代表了仓库的名称，右边的蓝色的内容是代表这个仓库下载下来解压的目录。我们会有一个工具，分析这个 xml 文件，把服务器上的仓库下载到本地。这个工具就是刚才提到的多模块的工具git-mm。\n我们需要把这个清单文件放到服务器的一个仓库里面，然后用 git-mm 的 init 与 sync，自动地把列表中所有的仓库下载到本地。下载完毕之后，就可以看到本地的目录已自动按照我们的定义创建好了。开发人员下一步进行开发的时候，用 start 命名在本地产生个人开发分支，这个开发分支不需要在服务器上存在，只需要在本地创建就好了。接下来开发人员就可以在本地进行一些修改和Git提交。最后可以通过一个 upload 命令，一条命令把本地的提交推送到服务端并产生 Merge Request。最终我们看一下 upload 命令结束的输出内容：\n每个代码仓库都有一个 Merge Request 的 URL 链接，并且最后有一个总的 Merge Request 容器。我们打开下面这个容器的 URL 之后，会看到这一个页面：\n这个页面上可以看到所有代码仓库的Merge Request 链接，并且开发人员本地创建的开发分支会变成Merge Request 的描述内容的一部分，分支并不会在服务端真实存在的。\n总体上 OMEGA 的工作流程就是这样的，开发人员不需要 fork 仓库。通过 init 和 sync 下载所有的仓库，然后在本地创建一个分支，进行相应的开发工作，最后通过 upload 把修改推送到代码平台的服务器上，产生一个Merge Request。同时平台发送消息给相关的 pipeline server，启动相应的 CI 工程。如果 CI 工程不通过，或者 committer 审核不过的话开发人员可以进行修改并更新 Merge Request，没问题的话就可以删除本地的开发分支，进入下一步的迭代开发。\n同时在 pipeline server 上可以通过命令来记录各个仓库的快照情况，我们记住这个快照之后，就可以对每条 CI 的结果，每次代码检查的结果 ，包括发布的每一个产品的版本，进行源码回溯。我们可以通过这个快照，完全还原当时构建的时候每个仓库对应的一个提交点。\n后面推广了 OMEGA 这种集中式开发模式后，开发人员不再需要 fork 了，效率确实有很大提升。但使用了集中式的仓库管理模式之后，我们也发现了一些问题，主要集中在服务端。我们发现所有的开发人员往同一个仓库提交，后台会产生大量的 pack 文件，这些 pack 文件可能会包含重复的内容，为加快 git gc 的速度，我们会首先使用 git pack-redundant 命令来去重，结果发现这个命令会导致 CPU 和内存耗尽。最终定位到是源码中使用的算法问题，在优化了代码并推送到社区后，我们解决了这个问题。\n另外我们发现非常频繁的操作同一个仓库，会导致刚刚更新的分支丢失最新的 commit。比如下面这个例子，master 分支最开始指向 V1 版，有修改之后指向 V2 版本，再修改就是指向 V3，但经常发现这么一个情况， master 分支突然又回到 V2 这个版本。这个最终也是通过了一段时间的分析之后，我们发现这是一个源码的 BUG，最终也是把这个修改推送到了社区。\n那么我们回到可信这个话题，就是我们这个集中开发模式到底对我们说的可信有什么帮助？\n首先我们用 manifest 替代 submodule，我们可以进行仓库关系配置化；另用一个仓库不需要 fork，我们能够统一管控所有的仓库，包括规则我们都是统一管控的。另外 manifest 这个文件列表之外的仓库，我们不参与构建与发布，我们可以确定我们的仓库来源是可信的。还有在 pipeline server 上，我们记录了所有仓库的快照信息，对应的 CI，代码检查，包括我们的产品版本都是可以回溯的，是进行复原，可重现的。\n华为云 DevCloud 旗下的 CodeHub 代码平台，在今年年底的时候，我们会上线 OMEGA 开发模式。\n希望大家也关注一下 DevCloud 的相关产品的特性发布。DevCloud 提供了一站式 DevOps 的各种工具与平台，包括我们的项目管理，代码托管、CI 流水线，代码检查、编译构建，包括相关的测试工具，包括版本的发布管理，以及云端的 CloudIDE。希望大家以后对华为云 DevCloud 相关的产品多一些关注，谢谢大家。\n关于作者 孙超\n华为云\nBU 代码平台 Committer\n","permalink":"https://devopschina.org/blog/huawei-cloud-devcloud-explores-large-scale-team-git-collaboration/","tags":["DevOps","Git","DevCloud"],"title":"华为云 DevCloud 在大规模团队 Git 协作的探索"},{"categories":["演讲"],"contents":" 本文内容选自中国 DevOps 社区年会 · 2019 年会，苏宁金融孙捷老师分享的《支撑万亿交易量的苏宁金融紫金大盘 AIOps 平台架构设计及实践》实录。\n 大家下午好！非常荣幸今天有这个机会跟大家一起交流 AIOps 的话题。先简单做个自我介绍，我先后就职于 IBM 和苏宁金融，我所在的技术管理中心负责苏宁金融 1000 多名研发人员的技术方面的管理工作。比如系统规划和架构管控、技术规范的制定和推广、以及 DevOps 和 AIOps 方面的事情。\n我今天分享的内容包括 4 个部分：首先是回顾一下苏宁金融的发展历程，以及技术运营能力的演进路线；介绍完这个背景后，分享一下我们的技术运营平台紫金大盘的架构设计，第三个部分介绍我们的落地实践；最后聊一聊过程中的心得体会。\n先介绍一下苏宁金融的发展历程。\n苏宁金融从成立于 2011 年，从第三方支付开始做起，主要服务于苏宁易购的电商场景，到了 2013 年的时候开办商业保理和基金销售支付结算，2015 年开办消费金融和企业征信业务，2016 年开办了基金销售业务和融资租赁业务，并成立上海研发中心，2017 年苏宁银行开业，现在是 2019 年已经 C 轮融资，估值 560 亿，这个过程中整个苏宁金融的业务是快速增长的，交易量从百亿的级别增长到万亿级，这对我们的技术运营能力提出了新的挑战。\n首先我们的系统越来越庞大和复杂，苏宁金融达到了 1000+ 的系统，5W+ 的服务器。而整个苏宁易购集团现在是 4000+ 的系统，27W+ 的服务器。如此庞大的系统，带来了高昂的运维成本，我们投入在设备上的成本 3~4 倍于运维人力成本，因为设备投入的成本是一次性的，但是人力成本会随着时间的推移不断增加，我们研发团队有 30% 的人力投入在运维。我们的运维能力也得到了挑战，生产环境发生的 70% 的严重问题都是人导致的，而且问题的感知和定位速度往往要 1~2 个小时。大家知道，线上服务每一分每一秒都会影响公司的财务指标，生产故障会给公司和用户的利益带来直接的损害。\n这是我们的技术运营能力的演进路线，2011 年苏宁金融刚起步的时候，是一体式架构，这个大家都很类似，都是从一体式架构起步，日志量是每秒 1GB，监控手段是 SNMON，还有堡垒机和 Zabbix。2015 年的时候，做了一次比较大的重构，这个时候做了微服务的拆分，系统规模增长了将近百倍，这个时候研发了第一代的紫金大盘，那个时候的日志量是每秒1GB左右，也增加了一百倍。我们通过统一日志的格式、统一的采集，还有统一的实时计算和告警做系统监控。到了 2017 年的时候，由于出过严重的事故，对业务连续性要求更高了，这个时候把系统的多活能力建设提到了很高的地位。我们 2017 年开始做双活，做了双活以后，同时有2个机房可以提供服务，原有的紫金大盘的架构就不能满足多活的要求了，所以紫金大盘也做了多活架构改造。另外这个时候的日志量达到了每秒 1TB 左右，为了便于快速定位和解决业务问题，我们做了一键定位平台，可以根据业务单号或者会员号一键定位业务链路的故障，并给出解决方案。\n到了 2019 年，交易量已经过万亿，这个时候我们开始往第三代紫金大盘的方向做，现在业务量达到每秒 10TB 左右，比 2017 年又有十倍的增长，我们现在是做 AIOps 平台化，这块主要是有业务保障、成本管控、人效提升三个方向。\n接下来我介绍一下我们第三代紫金大盘的架构设计。\n先介绍一下 AIOps 的体系框架，大家都知道其实技术运营是属于 DevOps 中的一个领域。DevOps 还有其他的领域，比如说持续交付、敏捷开发管理，还有应用设计、组织架构、安全管理方面。而 AIOps 其实是技术运营的高阶实现。这块有三个领域，我用了一个天平的形象来表达。我们的根基还是业务的稳定性，所以说业务保障域是在最下面，是一个基座。没有业务稳定这个基础的话，成本管理和人效提升都是空谈。业务稳定的基础上，成本管理和人效提升是一个相互平衡的关系。\n业务保障域首先是监控能力，这是最基础的。包括对故障的检测、诊断、恢复、预测，故障预测是基于前三步积累下的历史经验，总结出故障的模式，从而进行预测。其次是应急事件的管理，我们有一套快速的应急响应机制，在生产故障发生时把大家调动起来，集合最大的力量解决生产的问题。生产问题解决掉以后是事件根源的分析，也就是事后的总结，分析出根本的原因，最后做总结改进。\n成本管理域也是两块，一块是容量管理，容量管理首先是硬件利用率优化，这是我们今年重点做的这块，现在来说我们整体的利用率不到5%，其实是巨大的浪费。其次是基于容量的预测做容量的规划和管控工作。最后是弹性的扩缩容以及性能的优化建议。\n第二块成本优化主要是硬件成本优化、人力成本优化、采购建议，我们采购硬件的时候，如果提前采购了，用不上也是一种成本的浪费，如果采购慢了会影响业务发展，这也是需要智能化的。还有投入产出比的优化建议，这个是结合人力成本和业务的KPI指标来做。\n提升人效域，首先是运维的知识库，知识库可以节约运维人员的学习成本，基于知识库可以做容量预测，提高预测的效率。\n变更管理方面，并行研发这个刚才刘超老师也讲了，现在苏宁金融的测试环境已经可以做到一键创建测试环境，随时满足并行研发、并行发布的要求。还有智能决策，我们现在的运维决策基本上都是根据人的经验做，但是人是会流失的，知识也是会流失的，如果我们把这些知识固化到系统里面智能的做决策，也是可以提高效率的。\n这个是我们紫金大盘的整体架构，分为四个部分。“心”是服务工作台，其职责是协调“眼、脑、手”提供的中后台能力适配终端用户需求，包括人效提升、业务保障、成本管理三大场景。“眼”是数据云平台，把包括物理资源、虚拟资源、业务、应用、存储、中间件在内所有运维实体的整个生命周期的数据都统一汇聚在数据云平台并进行数据管理和治理。“脑”根据“眼”看到的信息进行快速决策，并给“手”发出执行指令。包括负责存储静态知识的“幻识”知识图谱和负责动态决策的“银河”算法平台两个部分。“手”是自动化运维平台，用自动化脚本操作替代人工操作，包括配置管理、服务管理、运维工具、监控工具、持续交付流水线等。这是一个“心眼脑手”四位一体的 AIOps 智能运维平台。\n这是我们的技术架构，我们的数据云平台分为三大模块，第一个模块是数据集成，数据集成负责采集数据，可以开发数据集成任务，例如从数据库直接捞取数据。第二个模块是数据开发IDE，提供了数据开发的可视化操作和编辑的能力。可以通过所见即所得的方式来编辑数据开发的任务，例如数据的加工，还有数据的计算。第三个模块是数据存储，我们封装了多种中间件，HDFS、ES、HBASE、Hive、Druid、Clickhouse 等。\n算法平台也是分为三部分，第一部分是算法路由，它的职责是负责把前端的不同业务请求分发到后端的模型计算服务集群上去，这个模型计算服务集群一般根据业务的相似性，或者算法技术的相似性做一个集群的分割，满足不同的算法服务要求。模型的管理，可以提供统一的模型部署、配置功能，以及模型准确度的度量、评估功能。但是现阶段模型的训练是在我们公司另外一个平台上。\n幻识知识图谱同样分为三个部分，首先是以 JanusGraph 作为基础的知识图谱数据库，另外还有图谱管理服务，提供了图库管理、图谱开发、监控告警、配置管理功能，通过统一的 API 网关提供服务。\n自动化运维平台就不详细介绍了。\n再讲一下我们实时计算的高可用设计，这是 2017 年做多活改造的时候设计的。假设有两个机房，一个 A，一个 B，假设 A 是主机房，正常流程是走的蓝色路线，Kafka 做日志的采集，Flink 做一层计算，Kafka 汇聚分机房的数据，Flink 做多机房合并计算。当机房宕机的时候，主机房自动切换到 B 机房。右边橘色的流程就会苏醒，所有的合并计算在 B 机房计算，保证了双活。\n下面介绍一下落地案例。\n先介绍一下业务保障域，一个比较经典的智能问题问题诊断场景。\n在互联网零售业务中，为了吸引新用户注册或者增加老用户的活跃度，经常会做支付促销让利活动，但是同时也吸引了逐利而来 “羊毛党”、“黄牛党”和“灰产大军”等非正常用户。有限的营销资源如果被非正常用户大量占用，会导致正常用户无法参与营销活动，从而给公司带来营销资源的浪费以及未来收入的损失，所以公司会针对各种营销活动进行风险控制，对疑似非正常用户的请求进行拦截。一般而言 “营销活动风险拦截量”这个 KPI 会在一个稳定的区间内波动，当这个 KPI 突然上升可能是大量正常用户被拦截影响营销活动的效果，当这个 KPI 突然下降可能是风险控制模型失效未正常拦截非正常用户的请求。为了尽快诊断出问题的根因，以便于执行针对性的应对措施，运维部门组建了一个固定的 4 人数据分析小组， 每日至少花费 4 个小时使用 Excel 等工具进行KPI相关数据的人工分析，成本高昂，工作效率低且容易出错，急需智能诊断能力。\n当某个总指标发生异常的时候，我们怎么定位原因？当总指标发生变化的时候，一定是由下面的子维度导致的，这叫做涟漪效应（REF:Yongqian Sun, Youjian Zhao, Ya su, et al., “HotSpot:Anomaly Localization for Additive KPIs withMulti-Dimensional Attributes”, IEEE Access, 2018.），在这个图中总交易量发生变化是因为机房和交易类型 2 个维度发生了突变，导致总指标下降。\n这个案例有三大挑战，首先是可能的根因组合太多，导致搜索的空间过大难以用常规的专家经验和规则分析问题根因。其次是实时性要求高，当问题发生时需要从海量的属性组合中快速找到到根因。最后是根因定位分析的过程复杂，根因分析不是一个简单的分类或者回归问题，输出的根因是一个维度不定的集合，不能用常规的机器学习算法来解决。\nKPI 通常拥有多个属性，以“营销活动风险拦截量”这个 KPI 为例，假设其属性包括手机城市、证件城市、IP城市、营销活动 4 个属性，每个属性都有不同的取值范围。我们可以针对每个不同的属性组合记录一段时间内（比如：每分钟）的 KPI 值，例如：（手机城市=北京，证件城市=上海，IP 城市=福建，营销活动=首单立减），这是一个 4 维的 KPI 值。由于 KPI 值具有可加和特点，这些细粒度的 KPI 也可以被聚合为粗粒度的属性组合。例如，手机城市=北京，证件城市=上海，IP 城市=福建，其他属性不做限制，这样的 KPI 可以被表达为（手机城市=北京，证件城市=上海，IP 城市=福建，营销活动=*）其中 * 是通配符，这是一个 3 维的 KPI 值。基于不同的聚合程度，我们将元素分类为不同层次的数据立方体，从低层到高层维度越来越高，元素的数量变得越来越大，如果元素的数量有 n 个，那么可能的根本原因就有 2n-1 个。\n我们的算法流程是这样的，首先来自各类运维实体（物理资源、虚拟资源、业务、应用、存储、中间件）的原始明细数据被数据云平台汇聚存储在 Hive 数据集市中；然后 Spark 把原始明细数据按照运维人员关注的维度聚合成细粒度的 KPI 数据并存储在 ES 中；当用户使用 β 地动仪进行根因分析操作时，部署在“银河”算法平台的 SFRD-FRCA（SuningFinanceR\u0026amp;D-FastRootCause Analysis）算法模型即根据用户的指令查询 ES 中的 KPI 数据并进行智能根因分析，最后将分析结果通过β地动仪可视化给用户。\n这是核心的 SFRD-FRCA 算法模型。可分解为 4 个关键过程，首先预测值算法根据 ES 中存储的某个时间点的实际数据立方体计算该时间点的预测数据立方体，并输出；然后使用可能性评估算法和搜索算法从低层到高层逐层计算每个根因组合的可能性得分并根据每个根因组合的可能性得分对搜索空间进行搜索，得到每层的最佳根因组合。最后将搜索出来的每层最佳根因组合做偏移修正并返回修正后的最终根因。\n下面把这四步一一介绍一下。\n首先是预测值的计算。预测值计算的目标是根据 ES 中存储的某个时间点的实际数据立方体计算该时间点的预测数据立方体，并输出作为后续流程的输入。由于该场景对实时性的要求很高，所以要求预测值算法不仅有稳定的准确率表现还要有较低的时间复杂度。经过大量实验比对 ARIMA（整合移动平均自回归）、EWMA（指数加权移动平均法）、Prophet（Facebook 的时间序列预测算法）的实际效果发现。ARIMA 算法对于单独的 KPI 预测效果比较好，但是对大量不同的 KPI 的平稳性难以度量，存在一定的误差。EWMA（指数加权移动平均法）算法时间复杂度低、表现稳定，但是灵活性稍差，存在短期噪声。而 Prophet（Facebook 的时间序列预测算法）算法基于所有历史数据做训练结果精度较高，但是在不同的 KPI 上表现差别较大，且逐点计算的速度较慢。所以最终决定采用时间复杂度最低的 EWMA（指数加权移动平均法）算法，并根据预测区间进行滤波，去除波动较小或者与总体趋势相反的波动噪声，提升预测效果。\n可能性评估算法的目标是根据数据立方体的实际值与预测值之间的差异用可能性评价公式计算根因可能性得分，以便于后续的搜索算法根据可能性得分来搜索最优根因组合。可能性评价公式可评判出一组结果是根因的可能性，得分越高则是根因的可能性越高，得分介于 0 到 1。可能性评价公式需要计算向量距离，在实际项目中我们通过大量实验发现只用单一的距离函数在特定根因组合场景下会表现不佳，而采用多种距离函数进行组合计算可以获得更加稳定的表现。最终我们的距离函数采用余弦相似度、Pearson 相关系数、KL 散度、JS 散度进行组合计算，将不同距离函数计算出的 Score 进行加权合并。\n搜索算法的作用是根据根因的可能性得分进行根因搜索，搜索出最有可能的根因组合。为了应对这个场景中巨大的搜索计算量需要有效且高效的搜索算法。我们的思路是采用一些已知的擅长巨大搜索计算量的高级算法，而不是重新人工探索开发算法。受 Alpha Go 在游戏中成功采用MCTS的启发，我们采用 MCTS 算法进行搜索，在限制了搜索次数的情况下，搜索出可能性得分最高的元素组合。同时设置了可能性得分的上阈值和下阈值，当搜索出的根因组合的可能性得分大于上阈值时，终止搜索返回结果。\n然而即使对于 MCTS 算法来说， 的时间复杂度也不是一件容易的事。为了减少搜索计算量，我们应用了分层修剪策略。基本思想是，在搜索较低层后，搜索算法会在更高层中修剪一些不太可能是根本原因的元素。简单来说，就是如果父元素具有非常低的可能性得分，则每个子元素不太可能是根本原因，因此可以被修剪。这种方法在思路上与关联规则挖掘中的频繁项集算法非常相似，我们将修剪方法称为分层剪枝，因为其修剪策略使用层次结构信息。\n偏移修正算法的目标是对上一步计算出来的每层最佳根因组合做偏移修正并返回修正后的最终根因。我们在实践中发现，由于算法本身结构的原因，可能会输出可能性得分相近的多个答案，这时候需要一种决策机制来选择最终答案，确保最终的答案尽可能的准确，通过大量实验这里我们最终选择了最简单有效的奥卡姆剃刀原则，当多个根因得分相近时，选择更简约的根因，将层数和根因组合数加入公式，层数越深或者根因组合越多，最终得分则越低。\n应用在实际场景中时，SFRD-FRCA 算法模型的准确率在 90% 以上，平均响应时间在 30 秒以内，表现非常优秀，已经大规模应用于苏宁的互联网金融领域。在“营销活动风险拦截量”KPI的根因定位场景中，问题的诊断时间从4小时以上降低到 10 秒，诊断准确率达到 99%，且不再需要固定数据分析小组负责专项工作，提高了工作效率的同时节约了大量人力成本。\n第二个实例是我们的硬件成本管控，这块是今年做起来的。\n我们每年的成本都是呈一个翻番的形式增长，但是我们的硬件资源利用率始终是保持在很低的水平。之前业务的稳定性是第一的，为了保障业务的稳定会不计成本的扩机器，并且业务刚开始爆发式增长的时候，很少会关心成本，从而导致了这个现状。\n这个是我们硬件成本管控平台的应用架构图，属于 AIOps 平台整体架构的一部分，不过里面的东西是跟硬件成本相关的。比如说我们的数据云平台里面的数据主要是调用链的数据，还有压测平台的数据以及应用的监控指标。知识图谱里面，比较关注运维实体，实体之间的关系，实体的画像、交易链路的画像等。\n这是硬件成本管控平台的技术架构图，来自运维实体数据和监控指标数据被汇聚到数据云平台，经过算法平台硬件成本管控计算集群的分析和处理由，由服务工作台提供各类成本管理功能。\n这是产品效果的截图，图中是缩容效果分析功能，我们可以看到每个月缩容节约了多少费用，每个月节约多少硬件资源。\n2019 年截止目前已经节约了硬件成本 15%，而苏宁金融集团的硬件成本费用是亿级的，所以大家可想而知这项工作的价值。另外我们的开发小组只有一个产品经理，四个开发，所以投入产出比是非常高的。明年这个产品计划为全集团服务，预计节约的成本可以上亿。\n最后介绍一下人效提升域的案例。\n相信各个研发团队都经常遇到过类似的场景：\n  不同版本的需求争抢测试环境，系统的测试环境只有 2 个（SIT、PRE），当一波需求高峰来临，上线时间还重叠，这个时候怎么办呢？排优先级，牺牲掉相对不重要的需求（其实也是很重要的需求），这样可能会带来商业价值的重大损失。\n  同一测试环境的并行版本会互相干扰，比如在消费者中心和中台中心的 PRE 环境上都有版本在开发测试，而且是不同上线时间的版本，那么不同版本的发布就会对测试产生干扰，测试结果受发布影响就会不稳定。\n  搭建测试环境耗时长成本高：测试环境不足，那么安排人搭建个环境吧？往往要数百人天，时间要长达几个月。\n  固定多套环境浪费资源：咱们并不总是需要 3 套，4 套测试环境，当一波业务需求高峰过去，多套测试环境就成了浪费，此时拆也不是，不拆也不是。\n  一键建站目前正在做第二阶段，第一阶段做的是一键拉起整个站点，但是这样消耗的硬件成本比较大。目前二阶段做的是轻量级建站，就是这个模型。跟前面刘超老师的方案不同，我们除了配置管理系统、DNS 服务外，数据库等中间件都是放在基准环境的。这个案例比较有挑战是双向的路由，单向路由指的是从特性环境到路由环境，这种比较简单，因为是多对一。比较难的是从基准环境，再找到原来的特性环境，这是一对多。图中有三个环境，基准环境，两个特性环境，我们在技术上也是采用了类似于刘超老师说的流量染色的原理，不过刘超老师是从网关开始染，我们不太一样，我们会用多种路由因子组合计算，比如分组标识，又或者从客户端开始的染色标识。\n关于一键建站产品的价值，一个是提升并行研发能力，这是最核心的，它可以提升交付速度、提升公司的业务竞争力。第二个节约人力成本，建一套环境需要耗费大量人力资源，使用一键建站可以用复制的方式快速交付环境、节约人力资源。第三个是节约硬件资源，按需搭建，资源复用。第四个是提升测试效率，我们过程中开发了很多测试工具，例如挡板工具、测试数据银行等。\n最后是如何从 0-1 打造一支 AIOps 的团队。\n最根本的是要聚焦公司的战略，而团队的规划一定要和公司的战略合拍，比如说团队做 AIOps，绝对不适合在 2011 年的时候开始做，那个时候最核心的是业务的发展，那个时候我们做技术运营，只要能够支撑当时的业务体量就好了。堡垒机 + Zabbix 就可以搞定了，而现在这个阶段做 AIOps 就比较符合公司的战略需要。\n其次我们要根据公司的战略主动规划和寻找资源，而不是被动等待。例如开发小组人力不足怎么办？这个时候应该主动去规划：我要做 AIOps，我要为公司这么大的业务体量提供技术支撑，我需要几个 AIOps 架构师，我需要几个算法专家，这个时候跟领导主动申请相关资源，只要提的要求符合公司的发展战略，公司一定会同意。\n然后 “胜利才是最好的团建”，团建最好的方法就是带领团队不断取得胜利。我们做 AIOps 是从一些容易开始并且应用价值高的场景入手，用快速迭代的方式以最低的成本进行验证。公司领导对我们取得的成果，做的事情非常支持，我们也向公司要激励，慢慢把团队建起来。另外我们也参加了一些外部的比赛，比如 2019 年的 AIOps 国际挑战赛我们进了前十，比同期参赛的阿里、腾讯队伍还高，这也是一种激励。\n最后是能力要可复制，因为团队人员毕竟会有流失，战斗力会下降。如果来一个新人能够快速地融入团队，能够快速把能力复制给新人，这才是一个成熟团队的标志。\n再下一步如何发展，又要回到公司战略，我们要根据公司的战略看，下一步公司发展我们需要提供什么样的支撑，做什么样的事，再次进行主动规划，这是一个良性循环。\n最后聊一下未来愿景，这个大厅是我们公司双十一大促的监控大厅，里面可以坐 500 个人，每次大促公司在技术保障上面投入的人力非常多，所以我们的愿景是以后一个人、一台电脑、一杯咖啡可以搞定 27W+ 的系统，谢谢！\nPS：我们团队现在也在招聘 AIOps 的架构师，还有算法架构师，大家有兴趣可以联系我。最后欢迎大家来苏宁易购购物，使用苏宁金融的贷款、理财和支付产品，谢谢！\n关于作者 孙 捷\n苏宁易购集团\n金融研发中心技术总监\n曾先后任职于 IBM 和苏宁金融，对 DevOps 和 AIOps 技术平台有深入的了解，擅长相关领域的产品设计和架构设计。\n设计过多款行业领先的 DevOps 和 AIOps 产品，并荣获数项相关专利；此外在开发管理、人才培养、团队建设等方面也颇有研究。\n","permalink":"https://devopschina.org/blog/design-and-practice-of-aiops-platform-architecture/","tags":["DevOps","AIOps"],"title":"支撑万亿交易量的苏宁金融紫金大盘 AIOps 平台架构设计及实践"},{"categories":["演讲"],"contents":" 本文内容选自中国 DevOps 社区年会 · 2019 年会，马云雷老师分享的《AI 如何赋能 DevOps：数据驱动全栈工程师的实践》实录。\n 大家好，我是来自阿里云的技术同学，我叫马云雷，今天给大家的分享的主题是《AI 如何赋能 DevOps：数据驱动全栈工程师的实践》。今天我首先从我的经历开始，分享我对 DevOps 的理解，以及我们在 DevOps 领域内所面临的挑战；然后分享我们如何借助于数据中台解决我们面临的各种各样的挑战，最后通过一系列案例分享数据和 AI 智能驱动的 DevOps 实践。\n首先看一下我的经历，我是 2012 年加入阿里云，最开始是一个研发岗位，为阿里的分布式系统做研发，这个阶段，测试的事情由测试的团队来做，运维的事情由运维团队来做，我只需要关心我写的代码就可以了。后来有一天，测试开始转型做研发，测试的事情没有人做，怎么办？这个阶段就需要分出一些时间把测试的事情接过来，你自己开发的功能自己去做测试，自己给代码质量兜底。再后来运维也开始转型做交付，这个阶段运维的事情我也要去接过来，自己开发的功能自己去做升级的维护，做各种监控、告警。还有什么岗位？还有运营岗位，运营岗位转型了吗？没有，因为根本没有运营岗位。所以如果自己做什么新的功能，要做宣传推广，OK，你自己去写软文，自己去找渠道。想知道推广的效果怎么样，OK，去文章里面埋点，自己去追踪点击效果。\n这是我一个大致的经历，从最开始一个单纯的研发，慢慢做的事情越来越多。我相信很多创业团队，创业公司，大家都有类似的经历，人少事情多责任多，要做的事情非常多。虽然是一个开发岗位，还要做测试的事情，做运营的事情，做运维的事情。DevOps 是一个坑，什么责任都要抗。\n那么责任多，时间怎么划分？我作为一个研发人员，肯定是希望90%的时间写代码，优化算法。还有10%的时间可以留出来可以和产品经理做一些友好的讨论，讨论需求和排期的问题。但是实际上只有20%的时间来写代码，其他的时间做什么？帮用户调查问题，处理工单，做线上的故障恢复等等。用户提了一个工单，你要立马放下手中的工作去帮用户调查问题。怎么调查？到机器上抓日志，原来我们可以有70台小机群，用 pssh+grep 很方便。慢慢我们的业务增加了之后，增加到 5000 台的规模，就开始有一点吃不消。再后面，发展到 N 个 5000 台集群，这个时候原来的模式已经玩不转了，环境越来越复杂，系统越来越复杂，我们要投入非常多的时间在运维上去。所以这个阶段我就发现我的时间被碎片化了，很难抽出大块的时间专心去写代码。怎么样解决这个时间被碎片化的问题？我们原来做了很多重复性的工作，这些工作可以总结和沉淀下来，通过工具帮我们去沉淀。我们原来需要调查问题的时候，才登录集群要抓日志；现在做一个采集日志的工具，把所有日志的实时采集到云端，当需要看日志的时候，我立马就可以在服务端看到所有的日志信息。原来需要到机器上搜索日志，现在在云端做倒排索引，直接就可以搜索到整个集群的日志。原来我可能要用 Excel 做一些数据分析的工作，去分析我的运营效果怎么样。现在在服务端实现一套实时分析的计算引擎，再加上可视化功能，帮助做各种各样的报表。原来调查问题的时候要登录集群上，用 vim 打开集群上的日志，看文件上下文是什么样子的。现在在云端做一个上下文关联的功能，直接在云端就可以看到所有集群上的日志和上下文信息。原来调查问题可能依赖于人的经验。现在通过 AI 帮我们做自动化的事情。\n关于数据采集、搜索、分析和可视化，我们可以把它抽象成一个数据中台，帮我们解决采集和计算问题；关于 AI，在数据中台之上帮我们用算法去做各种样智能化的事情。\n所以总结下来我们希望通过数据中台帮我们实现数据驱动的运维，来代替原来的人工驱动。借助于 AI 帮我们实现自动化、智能化。通过这种数据驱动加上智能自动化的运维帮我们节省被碎片化的时间。\n如果我们要做这样一个数据中台会面临哪些挑战呢？首先就是数据太少，如果我们抓取的数据太少的话，那么我们的信息量就会太少，在分钟级别的监控里面可能很多信息就被平均掉了，我们只有抓秒级监控才可以看到我们所关心的数据。第二个是实时性的挑战，我们做线上故障恢复的时候，都希望是说可以尽快定位问题的答案，尽快去恢复，这就是一个实时性的需求。如果我们找到答案太慢，可能已经错过了一个最佳的自救的时间。第三，系统越来越复杂，我们的需求是越来越多的，我们每加一个需求要加一个模块，那么维护整个一套系统其实是一个非常大的挑战。最后是数据太多的问题，数据太少是问题，太多也是问题。太少的话信息量不足，太多的话很多重要的信息被淹没。关于数据规模的问题和数据速度的问题可以通过数据中台来解决，数据中台帮我们通过算力来换取一个数据的速度和规模；而数据太多信息爆炸的问题，我们用AI算法来换取对数据深入的洞察力。\n总结下来，数据中台具备的能力，第一个就是数据采集，数据采集帮我们从各个数据孤岛中，从各种环境中，把各种各样的格式的日志统一采集，然后以统一的格式被存储起来。原来数据可能在手机上，可能在网页上等等各种各样的环境，格式也不一样。统一采集之后， 我们就有统一的格式，以后分析就非常方便了。数据采集帮我们做的脏活累活，其实是帮我们节省了很多的时间。数据采集之后，中台要有二次加工的能力。为什么要二次加工？因为我们采集过来的数据可能包含着脏数据，垃圾数据，我们要过滤掉，做一些转换和富华。增强数据质量，数据质量增强以后，分析的时候才可以得心应手。接下来就是一个查询分析的能力，中台提供的进行交互式的查询分析，可以在秒级别分析上亿日志。通过这种查询分析能力你可以尽情的探索你数据里面包含了什么价值。查询分析依赖于人的经验探索数据，那么我们还可以借助 AI 自动探索数据，这就是 AI 的预测能力和异常检测能力以及根因分析的能力。通过数据中台将 AI，帮助我们去获取对数据源的可观察性，进而通过数据可观察性，实现对运维系统的可观察性。\n我们前面介绍了数据中台的，接下来我会以一系列的实践去分享我们怎么样利用这样一个数据中台帮我们解决我们 DevOps 所遇到的各种各样的问题。\n我们说到数据驱动的运维，首先我们会面临大规模的数据，如何去找有效的信息，这就是一个发现的过程。原来我们通过 grep 搜索的关键字，通过 awk 做一些简单的计算；借助中台，我们可以通过交互式查询去不停探索答案，也可以通过异常检测帮助我们智能的检测数据里面到底有什么异常的信息。\n当我们发现一些有效信息以后，接下来怎么办？我们要从这些线索出发，然后去找更多的线索，去找关联关系，去找因果关系，这个就是上下文钻取，以及聚类。那么通过这种钻取我们可以找到一系列的更加关联的信息，我们最终找到了信息足够多之后，我们要确定最终的一个答案，这个就是根因分析，帮我们确定故障的根本原因是什么。\n我们做数据分析最简单的形式是什么？我们上网的时候，用的最多的工具是什么？是搜索引擎，搜索可以帮我们尽情探索数据中的价值。原来我们到机器上搜索日志，数据在文件中是有序的存储的。而在采集的过程中，为了性能的考虑，会以乱序的形式存储下来，当然我们搜索完之后，可能我们看到的是乱序的日志。如何从这些乱序的日志中找它的上下文信息呢？我们为每一条日志指定一个编码。当我们搜索到一条日志之后，去看它的编码值，再去计算它的下一条编码是什么，根据编号搜索下一条日志。通过这种方式定位下上文。\n我们看一个搜索和上下文的样例。我们把所有集群的日志都被统一的采集到一起，然后去搜索整个集群日志，这个时候如果我们对某一台机器感兴趣的话，我们可以把机器的 hostname 加入到搜索条件里面去。这个时候如果我们对某一些关键字不感兴趣的话，我们可以过滤掉。这个时候我们定位到 9 条日志，我们对这 9 条日志感兴趣。我们可以去看上下文的信息。在上下文里面，可以以上下文严格有序的一种形式去看这条日志前后发生的一些事情，通过这种方式找它的一个因果关系。\n搜索针对的对象是什么？是日志；日志是什么？是一种事件类型的数据，里面包含的信息有事件的发生的时间、对象、操作，还有各种属性，关于事件的描述是非常详细的。除了这种事件日志，还有一种指标日志。指标日志有时间，有一个汇总的数值，例如用一个数值表示这一分钟有多少个浏览量。这两种数据有什么区别？事件日志描述的是一个非常详细的信息，所以它的体量和规模是非常大的。它代表的是我们从局部去观察问题的一种视角。而指标数据是一种汇总的信息，所有它的体量非常小。但是它代表的是一种全局视角，概括整个事件的信息。例如，我们一分钟有 1 万次的访问，我们用这种事件日志来表示可能就真的是 1 万条数据。用这种指标日志可能就是 1 万这一个数字，这就是两者之间的差别。这两种日志之中是不是割裂的？不是，我们可以通过计算把事件日志转化为指标日志，一个是代表大视野，一个代表小视野。我们可以充分利用计算在这两种视野之间切换去调查问题。\n举个例子，我们面对一个事件日志，可能对某一些维度感兴趣，比方说时间维度，那么在时间维度中统计趋势指标；或者对IP维度感兴趣，可以统计出 IP 分布，他们这个时候我们就把一个事件日志转化成了指标日志，从局部视野跳到全部视野看待问题。\n当我们看到某一个数值比较特殊，我们对它进行下钻，增加维度，进行更多的统计。比方说我们按照不同的 IP 统计出它的趋势。假如统计出来的各个维度之间，我们对某一些维度感兴趣的话，我们把它单独拎出来，跳回我们原来的事件日志当中，帮我们搜索对应的事件。这样的话我们就形成了一个调查问题的闭环，我们从事件日志出发去统计它全局的信息，再回到原来的事件，这是一个闭环。\n我们看一个指标日志统计的样例，首先对所有的日志统计每分钟的趋势。在这个趋势里面，我们没有发现问题怎么办？我们把它改成在秒级监控，在秒级监控里面，可以发现一个明显的波动信息。\n如果我们对这个波动信息感兴趣怎么办？我们可以下钻，增加一些维度进行统计，去看每一个维度的波动信息是怎么样的？这个时候我们就发现在所有的统计出来的维度里面，有紫色这个维度的波动性和我们在秒级监控里面看到的统计是一模一样的。我们对它非常感兴趣。就把紫色这条维度再单独拎出来，再回到事件当中去搜索，再进行下一轮的迭代，逐步靠近我们的答案。\n事件日志的体量是非常大的，现在对于我们的业务来说，每天的数据量都在上涨，每分钟能达到上亿条的日志，日志这么多，重要的信息被淹没了怎么办？即使我们只关心错误的日志，但是错误的信息可能都有上千条，什么时候看完？我们通常对于这很多大量日志的这种场景，首先想的是排除法，比方说我们先把一些不关心的日志排除掉，逐步排除掉一些关键字，逐步的缩小数据的体量，慢慢靠近我们关心的信息。对于数值类来说，我们怎么样排除？我们可能统计数值的百分位，去统计它的 25 分位在哪里，75 分位在哪里？99 分位在哪里？假如说说我们对 99 分位感兴趣，只需要过滤出来 99 分位以上的数据，通过这种方式减少数值类型数据的体量。\n但是这种排除法不一定可以帮助我们找到所有我们所关心的问题，因为我们现在的业务实在是太复杂了，维度太多了。有一个真实的案例，就是有一次我们一个新版本发布，有一个边界的条件没有测试到，上线之后也没发现，直到用户跑过来问，为什么我之前可以用，现在不能用？现在开始报错了？我到这个时候才发现发现，真的是从升级那一刻开始出现一种新类型的日志，原来都没有这种日志。显然用排除法是没有办法帮我解决升级后的这种异常检测，怎么办呢？那我们引入了智能聚类。即使每分钟产生上亿条日志，可能里面不到100种类新的事件，只是说每一种类新的事件重复发生了很多次，所以造成整体数据的膨胀。\n通过这种分析数据之间的关联性，把数据里面的干扰信息过滤掉，提取出里面一些公共的特征，这个就是聚类。在这个例子中我们有 1300 万条数据，人眼去看这 1300 万条可能一天一夜也看不到。但是我们可以通过聚类，最后只有 35 条聚类的结果，这个时候我们去看 35 种类型的事件，其实一眼就可以看到，那么在机器上到底发生了什么事情。比如说，我可以一眼看到这是有这样一个 timeout 关键字，是不是要特殊的关注它？\n我们怎么样利用智能聚会帮助我们解决升级后故障发现的问题。我们可以通过对比升级后你的聚类结果和升级前了聚类结果，查看有没有什么差别，如果一个新的事件在升级之后出现了，而之前是没有的，这是特殊关注的。通过这种方式我们去做告警，及时发现问题，及时的处理，避免影响到用户。\n通过智能聚类实现对文本类的数据异常类检测。那么对于我们刚才说的 Metric 指标数据，怎么样做异常检测？最简单的指标什么？是一条平稳的直线，围绕这样一条直线，可能有一个很轻微的在正常范围之内的波动，对于这种数值我们设一个固定的阈值，可以很好的把一些大的抖动捕获出来。但是这是一种非常简单的场景，在现实的业务中其实没有这么简单的，现实的数据一定是有各种各样的波动。\n最常见波动是什么？是周期性。一般我们工作日它的流量比较高，到了周末流量又跌下去了，那就是一个周期新的波动，所以对于波动性的信息我们怎么样做异常的检测？我可以通过同比、环比，拿当前时间点的数据和上一个周期同一个时间点的数据进行对比，看看有没有发生比较大的偏差，这就是同环比算法。\n还有一种情况就是趋势性，对于互联网业务来说，增长是一种常态，没有增长的业务是没有前途的。在增长的趋势中，可能还有周期性的波动，以及扰动。我们所关心的那种异常的点可能被掩藏在这样一个增长的趋势中，对于人眼来说，其实一眼就可以看出来哪一个点是异常点。但是对于算法来说检测出来这样一个异常点是一个很大的挑战。我们的解决方案是通过机器学习，通过学习历史上的数据它的一个趋势性信息，周期性信息，然后去预测未来的点是什么样子的。那么把预测的点和真实出现的这个数据进行一个对比，那么当这样一个差值发生比较大的偏差的时候，就认为这是一个异常的点。通过这种方式去检测趋势性数据里面的一个异常点。\n不管是周期性信息还是趋势性的信息，它其实都是一种很规律的一种波动。那么还有一种数据波动称为断层。比方说原来我们一个机器，它的 CPU 很低。突然有一天你把流量切到机器上，它的 CPU 立马暴涨到另外一个水平，但是它的波动又没有什么变化，这就是断层。对于断层的数据，其实统计的时候是非常难的，因为在这样一个点里面它的导数是没有的。那么我们可以用专门的断层检测算法去检测出来。\n最后一个就是变点，变点是什么？就是在某一个点，它的波动形态、统计特征发生了变化。原来可能是一条平稳的直线，但是在某一个时间点假如说发生了异常，你的流量抖动开始发生了非常大的一个抖动，这就是一个变点。通过变点算法，统计所有数据里面的波动信息，然后对比不同点上的波动信息进行检测这种变点。这就是我们针对 Metric 指标数据，利用机器学习、统计算法进行异常检测的方法。\n当我们检测到异常之后，下一步要做什么事情？要找这个异常它发生的原因是什么？并且及时的去修复它。假如我们网站流量下跌了 7%，下跌是什么原因引起的？通常人工是怎么检测这个问题的？我们可能按照我们的经验逐步去排查，比方说我们先到服务端看一下，有没有错过日志；服务端没有，再看网络上有没有抖动。OK，那网络端没有抖动，接下来怎么办，再去看用户的统计上有没有异常的一些抖动，结果发现，用户的统计上有抖动的话怎么办？我们再去下钻，去看什么类型的用户发生了抖动。比方说不同的城市有没有抖动，不同的接入点有没有抖动？不同的客户端有没有抖动？结果发现在客户端这样一个维度，有数据是抖动的。那么我们再深入的下钻去找哪一种类型的客户端发生了问题。通过这种逐层的下钻，逐层去找，最终定位到版本因素造成了流量下跌。\n这是我们人工调查问题的一个方法，这一套流程走下来其实是非常耗费时间的。我们怎么样借助算法帮助我们做这种异常检测呢？这就是关联规则算法，大家都听说过啤酒和尿布这个故事：在一大堆物品当中，啤酒和尿布同时出现的频率非常高，所以我们认为它两个之间是有关联关系的，然后进行关联推荐。我们可以把这种关联推荐给映射到根因分析算法。比方说我拿了一个访问日志，访问日志里面有很多的错误信息，然后我们再把网络日志拿过来。结果发现在网络日志里面某个交换机经常会和这个错误日志同时出现，是不是可以认为这个交换机上出现了错误？\n如何找两个关联的项目，就是我们通过频繁集算法。我们把一份错误的日志拿出来，找这个日志里面它高频出现的一些数据集合。比方说我们在这样一个错误日志里面定位到 IP 等于 1002 这样一个用户，他出现的频率是 68%，那么是不是认为这样一个用户他就是造成我们错误的一个原因？不一定。为什么？因为这个用户可能在错误的日志中出现的频率比较高，但是在正确的日志中出现的频率也是非常高的，所以你不能简单认为他就是一个错误的原因。那怎么办呢？要通过差异集合算法进行统计，我们把一份完整的数据，按照是否有错误，分成正负两份样本，然后比较两个样本里面的频繁集有什么差别，如果某一个集合它在一个错误的集合中出现的频率比较高，而在正确的集合里面出现的频率比较低，就可以认为这个集合是造成错误的根本原因。\n如果我们再引入到时序维度，针对我们刚才说的网站浏览量下跌的问题，我们怎么样做这种根因分析呢？我们首先面对一个汇总的流量下跌的曲线，然后可以把我们所关心的维度都引入进来，例如地区维度，运营商维度，客户端维度全部引入进来，把各种维度自由组合各种各样的集合，那么我们算出来每一个集合它的一个流量曲线，计算算每一个集合它下跌的一个趋势，和整体流量下跌趋势之间的关联度，并且打分，按照分数的高低寻找根因集合。通过这种打分找出来一个集合，它对整个流量下跌的贡献是最大的。比方说我们最终统计出来上海这个地区所有的运营商流量下跌都非常的严重，打分非常高，那我们认为上海这个集合就是根因。\n我们看一个根因分析的样例，我们看到一个流量有一个上涨，我们要分析这个上涨是什么引起的。经过分析，我们得到一个唯一集合 i46，贡献了整个流量的上涨。我们从右侧看它的趋势，发现这个集合它的曲线和总的流量集合的一个曲线是完全的重合的，那么认为是这样一个集合，它贡献了这样一个流量上涨。\n我们再看流量下跌的样例，流量下跌的时间段之后，分析根因集合。然后找到了很多集合，每个集合都有一个打分，打分多少是代表了流量下跌关联度的关系。\n对于我们 DevOps 而言，我们不仅要关心我们所做的成果，还要关心我们的成本，因为拿堆资源做出来的成果不代表一个人的能力，用最少的资源做最大的事情才可以代表一个人的能力。我们通常做采购机器，然后等待机器到货、上架，最终部署这个软件，交付。这是一个原来传统的上线机器的流程。这个流程是很长的，一般过几个月才能拿到机器。现在有云服务，一键可以创建机器，当你需要的时候可以立马拿到资源，这样一个流程实在太方便了。但是就是方便背后其实也有一些其他的困扰。比方说我一次测试的时候买了一台机器，用完之后忘了释放，结果这机器在那里跑着一直产生费用，或者我在储存里面放了一大堆的数据，测试完全之后忘记了删除，过了很久，谁都不知道这个数据是干嘛的，谁也不敢删，谁都不知道这个数据删掉以后会不会影响其他的业务。但是这些资源一直产生的费用。直到财务人员发现你的消费比较高的时候，一般都会来踢你的屁股，说你部门成本怎么这么高？你要优化一下了。这个时候其实就已经是很被动了，为什么？因为这个时候我们去统计所有的资源，统计谁在用这些资源，这个流程是非常长的。我们可以通过主动的成本控制，去统计我们的资源使用量，实时去统计资源使用量，实时去优化。\n我们看一个成本控制的样例。我们把实时的把账单数据导入数据中台，然后可以统计出来，我这个月到底花费了多少钱，预测这个月大概花多少钱，以及每一个云产品花钱的数量。还可以去看，过去三个月的趋势是怎么样的，以及每一个产品的趋势。或者根据我们过去的趋势信息预测我未来三个月大概要花多少钱，利用这个数字及时的去申请预算。\n同时我们还可以在我们账单数据里面，根据统计信息看一下有没有一些异常的账单。比方说我在近三个月的消费曲线中，发现 10 月 1 号这一天账单发生了暴涨。我要抓出来到底是哪一个云产品产生了这么多消费？于是深入下钻到日志里面去分析，用刚才提到的根因分析的算法去找哪一个产品对一个消费的上涨贡献归最大，所以我们发现SLS这样一个产品，它的异常打分是最高的。那么我们就认为，这个产品出现的消费异常，及时的发出告警即可。\n我们做一个总结，我们介绍了调查问题的一系列案例，通过这些样例展示我们如何借助于数据中台，帮助我们做数据驱动，以及借助AI做一些智能化、自动化的运维。通过这种数据驱动和智能、自动化的运维，整体提升我们的效率，减少我们被碎片化的时间。\n互动问答 提问：请问，未来 AI 和 DevOps 的结合的话，还有哪些更实际的落地场景？\n马云雷：这是一个非常大的话题。\n提问：或者说是一个怎么样的一个趋势？\n马云雷：首先我觉得要从如何提升我们整体的一个研发的效率，节省我们运维的时间，帮助我们把整体运维，就是很多那种重复的工作节省掉，其实我觉得第一帮我们节省了时间。第二个帮我们发现里面的一些，我们人所不能发现的问题。比方说一些异常，其实我们大部分的时间是故障发生之后我们才可以发现它，我们可以借助AI，帮助我们及时的发现。第三帮助我们做预警，就是在故障发现之前就帮我们把这件事情做掉。\n关于作者 马云雷\n阿里巴巴\n阿里云\n日志存储 技术专家\n2012 年毕业于上海交通大学，加入阿里云日志存储团队，从0到1参与打造了阿里巴巴的自研日志平台，是阿里巴巴集团、蚂蚁金服集团、公有云的日志基础设施， 向客户提供日志的采集、存储、加工、计算等一揽子解决方案。专注于是实时计算引擎领域，以及数据驱动决策的方法论，关注增长黑客领域，尤其关注AI驱动的数据分析场景落地。\n","permalink":"https://devopschina.org/blog/how-ai-empowers-devops-for-data-driven-full-stack-engineers/","tags":["DevOps","数据驱动","AI"],"title":"AI 如何赋能 DevOps：数据驱动全栈工程师的实践"},{"categories":["演讲"],"contents":" 本文内容选自中国 DevOps 社区年会 · 2019年会，滕乐英老师分享的《招商银行 DevOps 实践及 DevOps 标准认证评估分享》实录。\n 大家好！我先自我介绍一下，我叫滕乐英，来自招商银行杭州研发中心。2005年加入招行，先是做了几年的开发，然后在2009年转做配置管理。从2014年开始，我们行开始接触 DevOps，我就开始从事 DevOps 相关的工作，直到现在。目前主要负责杭州中心及分行 DevOps 的实施与推广。今天我给大家带来的主题是《招商银行 DevOps 实践及 DevOps 标准认证评估分享》。主要从以下四个方面给大家做一个介绍：\n  第一部分，招行 DevOps 之困惑。\n  第二部分，招行 DevOps 探索历程。\n  第三部分，招行关键工程实践。\n  第四部分，DevOps 标准认证评估分享。\n  我们在 DevOps 实施初期，也是有一些困惑的，比如发布节奏。 早上我们也听了很多互联网企业的案例，是按天发布的，那么我们作为传统的金融行业，是否需要按照这么快的节奏去发布？是不是快就是好？这个问题需要我们不断去思考不断去实践摸索。所以关于发布节奏，我们这边是由开发人员和业务人员一起讨论商定的。目前一般是一个月发布一次，或者两周发布一次，这两种节奏也是业务和开发都比较容易接受的。 关于自动化测试，微软公司的单元测试覆盖率非常高，能做到100%全覆盖。这么高的覆盖率又是否适用于我们？从我们的角度，更多的还是希望开发通过实践，真正发现这个单元测试的价值，对他们的代码质量，包括线上质量确实有帮助，让开发自发地去做；而不希望像有的企业从上往下去强推。虽然说强推覆盖率能够很高，但是否能真正提高代码质量，提高效能？\n当然，我们现在也在推自动化测试。好的自动化测试，在保障项目、产品质量的同时，也能带来效能上的提升。就像上午熊节老师说的要提升质量，就得做 TDD。我们现在也有团队在试点 TDD，后续还会继续深入探索，希望能有正向的结果数据反馈，继而扩大试点范围。 接下来，介绍一下我们在 DevOps 上的探索历程。之前在杭州的 Meetup 上介绍过我们自研的 DevOps 流水线平台。所以这次我就快速带过，我们是在2014年开始接触 DevOps。在这之前我们都是手工去做编译，比方说进入 UAT 之前，组织级配置管理员会在 UAT 构建机器上手工编译代码，将源代码转化成二进制文件。因为开发的话，他们基本上都是在本地编译，如果存在依赖包在本地，未上传配置库的话，在 UAT 构建机器上编译就会不通过。所以在2014年我们开始尝试把写手工编译的工作进行脚本化。由于不同的团队，能力会有差异，有些团队技术能力非常强，所以他们可以自己去写一些自动化的脚本。有些团队比较弱的，我们就会提供一些模板，然后开发根据这个模板去编写他们的自动化脚本。然后我们就开始尝试做持续集成。那个时候我们使用的是商业版的持续集成工具。\n在2015年的时候，领导带队到国内外领先的敏捷企业去交流，看他们的敏捷实践具体是怎么落地的，包括 DevOps 这一块。我们开始尝试敏捷试点，扩大持续集成的试点，同时增加了两块技术实践，一块是技术债的管理，另一块是自动化部署。\n然后到了2016年，这个时候我们的 DevOps 正式起步了，我们根据总结出来的实践经验，开始自研工具平台。之前采购了商业工具，虽然说有定制化，厂商入驻的工程师能力也很强，但由于工具框架的约束，总归还是没那么灵活，加上我们体量剧增，性能上也无法满足我们的要求了。所以这个时候，我们就开始思考，是不是自研才是出路。然后，我们开始打造综合管理平台，改进源代码管理工具，并持续推动开发降低技术债。\n2017年，我们建立了内部的 DevOps 成熟度模型，持续推动 DevOps 实践落地，努力打造 DevOps 综合平台，包括持续交付流水线平台。\n2018年，持续交付流水线平台成熟了，我们的工程实践也全面落地了。开始要求开放平台的同学必须通过流水线平台去跑构建，sonar 扫描，发布制品库，自动化部署，才能将TAG同步到我们的项目管理流程上，才能提上线申请，同时我们在流水线上也设置了一些管控点，比如说技术债的要求，开源漏洞要求等等。如果质量门禁不达标的话，这条流水线状态是红色的，是没法上线的。这一年，协同工作平台也逐步成型了。\n到了2019，也就是今年，一方面是优化提升我们具体的工程实践，另一方面是持续改进我们的工具链。另外继2018年参加了 DevOps 标准3.0评估之后，今年领导要求所有运营一年以上的敏捷团队都要参加 DevOps 标准 3.0的评估。一来是想通过外部的力量来驱动开发团队优化具体的工程管理过程实践。二来是帮助我们组织级找到工具链的改进方向，持续优化我们的工具链。最终还是希望能够从用户的角度出发，打造一套简单易用的综合管理平台。 这是我们的 DevOps 工具链，大家可以看到我们内部用的工具非常多，在项目过程管理这一块，我们目前主要是用 JIRA，基于 JIRA 商业版做了一层封装，来打造我们的协同工作管理平台，即电子看板。目前是两周一个迭代去做的。Tracker 这一块，我们是基于 IBM 的一个产品框架封装的一个工具，主要用来管理专题、迭代，还有一些度量数据缺陷等等。VP 主要是管理我们的项目管理流程，需求、立项、ST、UAT、上线流程全部都在 VP 上。Conference，这个可能很多企业都在用，这个主要是管理我们的知识库，比如我们的一些用户手册，还有一些比方说技术上的问题、解答都在上面。ITIL 是在数据中心那边的，主要用来管理项目的发布流程。在配置工具方面，我们也是逐步演进的。我们最开始用的是 FIREFLY。FIREFLY 管理操作很简单，但是它的功能还不够强大。后来我们引入了 IBM 的一套工具 CC、RTC。现在我们基本上用的是码云，是一套基于 Git 封装的工具。然后构建这块的话，我们目前这些都是集成在流水线平台上的。用 Sonar 来扫描我们的代码，做一些静态代码规范性检查。用黑鸭扫描开源漏洞，如果扫出一些中高危的漏洞，流水线会失败。然后还有一些就是单元测试的一些框架工具。在部署这块主要是用的 UCD。基础设施这块我们用的厂商也是非常多，大家可以看到，招行还是比较开放的，业界有什么好的东西，我们都是积极吸纳，所以我们现在有用微软的，亚马逊的，pivotal 的，当然还有一些虚机。然后沟通协作这块，招呼、移事通这两个都是我们自研的。流水线的执行结果，也会通过招呼订阅号推送给项目干系人。在可视化这块我们用的比较多的是 TableLu，基于这个工具我们做了招行的度量平台，可视化了各个层级的数据报告，希望能够做到数据驱动过程改进。 这是我们 DevOps 综合平台的全貌。主要分协同工作服务，持续交付流水线服务，统一配置管理服务，广义测试管理平台服务，运维/运营平台以及度量分析服务。\n接下来重点介绍一下招行关键工程实践。 统一代码仓库，之前我们这边存在团队各自为政，私立“小仓库”,管理混乱，可读性不佳的问题，后来我们要求统一使用码云，并且统一规范，统一标准，易读易维护，也符合接入流水线的标准。 灵活的分支策略，由于不同的开发团队业务、开发模式会有不同，哪怕是同一个开发团队，分支使用场景也是又多又复杂，同时，分支这块是开发自主管理的，每个团队都有自己的个性化特点，所以从组织级层面看，是有点混乱的。所以现在组织级建议开发根据实际情况，采用灵活的分支策略，主推三种分支策略：分支开发、主干发布；主干开发，分支发布；主干开发，主干发布。明年会考虑制定一些分支策略与流水线套餐。 自动化编译。我们现在这块也是集成到流水线平台上，通过脚本或者是特定编译工具实现源码下载、编译。主要支持的框架有 Maven、Gradle，Ant 等等。然后主要支撑语言有 JAVA、C#、C++ 等等。这块我们不同于一些企业，之前我们去阿里的某事业部做过一些交流，他们为方便统一管理，选取的技术栈就是JAVA，大家统一用 JAVA 来编写代码。 但是我们行有非常多的遗留系统，所以这个技术栈和框架是非常多的，语言和版本也非常多，所以说管理起来非常复杂，构建环境也是非常复杂，所以支持成本非常大。我们现在加大力度基于 docker 和 K8s 建设持续交付流水线。实现编译环境的 docker 化和池化。定制了 CLI，可以自动探测编译语言和框架。 大家可以看到这个是我们基于镜像的流水线和 CLI。我们有非常多的 slave，支持动态快速创建，动态销毁。CLI 是标准化的，跨平台的，有自己的版本管理，可以动态加载配置，可以探索构建工具，然后可以自动升级，所以这块对用户来讲是非常简单易用的。持续交付流水线平台，现在我们是有两个版本，一个总行版的，一个分行版的。分行相对于总行能力相对会弱一些。但分行根据我们提供的这个操作手册去来配也是没有问题的。我们目前统计下来的话，国内一共有44家分行，有40家分行已经在用持续交付流水线平台。总行这边是所有的开放团队都在用。\n我负责分行推广，和分行开发人员的交互会比较多，有一家分行主动联系我说用了分行云，持续交付流水线之后，他们的研发效能提升了很多。这对我们来说是个正向反馈，是对我们平台的肯定。 静态代码扫描，这块因为招行有很多遗留系统，不少遗留系统的技术债务是比较高的，并且规则很多，开发人员对规则的抵触情绪会非常严重。因为自由惯了，你现在加以约束，他们肯定是会不高兴的。并且会对这些规则提出挑战。尤其是引用了一些开源组件可能根本就没有办法去改。或者认为这个问题并不是这么严重，打个比方，扫出来是阻断的，开发觉得这个顶多算是一个主要问题，所以怎么去提升我们的权威性。于是，我们制定了一系列解决方案。首先我们会建立一个度量和可视化，然后每个月去跟进。最开始的话，这个技术债要求是不能超过10%，运行一段时间之后，要求不能超过5%，不能有新增的严重和阻断。然后成立语言专家小组。比如说开发如果对某一个规则提出置疑，那他可以把这个规则发给语言专家小组，语言专家小组会进行评审，评审通过之后组织级可以把这条规则下线，或者调整严重等级，比如是阻断的，可把它调成主要或次要。 制品仓库，这块的话因为我们有三个中心，有研发中心、数据中心、测试中心。每个中心都各自管理的，所以导致有一些术语会不统一。依赖仓库也是散落在各处。虽然说同是研发团队，同是开发者，但不同的开发室，会有各自不同的 maven 仓库。这一块对于组织级来说其实是不便于管理的。并且FTP没有唯一的标识。二进制制品形成多种多样。缺少同步和高可用方案。\n所以这块我们是和 CMDB 配合统一了术语，然后与数据中心配合统一了制品的发布流程，用统一的工具管理各类制品。 大家可以看到这幅图，这个是我们制品库的样例图，第一个我们是用来管理我们的内部发布程序。就是开发人员编写了源代码，然后把源代码编译出二进制文件，流水线会自动把二进制文件上传到制品库去。 第二块是依赖包，像早前的话开发人员习惯性会把依赖包放到源码工具里面去，因为方便，依赖包跟源代码一起提交就可以了。但是现在我们是不允许这样做的，因为这样会导致源代码库非常大。我们说流水线我们要求快，如果代码库太大的话，就影响下载源代码的时间，它就没有办法做到快。所以我们现在是把这块依赖包剥离，放到制品库里面去。然后开发那边可以通过配置文件去调它的依赖库。另外一块是开源组件、中间件，这个是从第三方拿过来的，也是放在这里统一管理。我们走 docker 之后会有很多的基础镜像。现在基础镜像也会统一放在制品库里面，供开发去调用。然后开发也会打出一些应用的镜像，也会放在制品库里面。大家可以看到，在制品库里会有一些依赖定位的描述，比如说系统编号，发布单元版本。所以发布单元在我们这里是非常重要的。一个新系统过来，开发做的第一件事就是要规划他们的发布单元，发布单元是最小的管理单元，它是可以独立编译、独立部署的，但是不要求可以独立运行。 自动化部署的话，我们目前用的是 UCD，使用工具 UCD 定制部署流程。从制品库中自动获取发布包，按照预定义流程部署到目标环境。比如说 DEV 环境、ST 环境等。部署这块我们之前手工操作也是非常麻烦，并且我刚才提到了我们有测试中心、数据中心，比如说 UAT 测试，这个环境不是开发人员自己就可以下载安装包的。因为它是一个独立的环境，网段跟办公网是不通的，所以需要测试环境支持人员把这些包导到UAT测试环境上面去。生产环境也是，会需要数据中心的人，去把这个包导到生产环境上去。如果说当一天并发非常多的话，就需要排队，这样等待时间就长了，并且容易犯错，会影响部署时间和效率。我们之前走 CMMI，文档还是很全的，上线会有上线投产方案。对于部署的话，也会有安装说明书。安装说明书长，且无法保鲜。所以基本上每上一次线，可能都要把安装说明书重新写一下，因为可能有一些配置修改了。同时部署过程也是难以审计的，难以实现快速回滚。所以对于这块我们先是针对框架类的重点突破,比如基于 PaaS 平台的，然后针对高频发布类的应用重点突破。建立定期度量和可视化进展，查漏补缺。其实这一块推动起来还是比较容易的，因为开发切实感受到了效率的提升。\n接下来给大家讲一下我们的自动化测试这块。自动化测试一直是我们努力的方向。今天像熊节老师也说了，DevOps 做得好不好关键看自动化测试。自动化测试这块，我们也做了一些尝试，也有了不小的进步，但关于覆盖率这块，可能还是需要进一步的摸索。自动化测试（比如接口测试）这块做得相对好一些，因为是由测试中心的同事去做的。单元测试是开发人员来做。开发人员会去衡量业务功能开发和工程实践的投入与产出，考虑他们所谓的“性价比”。 大家可以看到这个是常规的金字塔模型，越往下，回归成本越低，效率越高，缺陷也更容易定位。越往上更加接近业务，也反应真实的需求。这是比较推荐的一个自动化测试的模型。\n大家可以看左上方的图，这个是我们早前的截图，是我们在用商业版工具的时候，当时就已经尝试做单元测试了，会把单元测试的报告集成到工具，方便集成人员查看。\n右侧是我们自动化平台的一个截图，上面有显示测试案例多少，多少通过了自动化测试等等。现在的话，我们基本上把单元测试的结果是集成到 Sonar 上了，可以在 Sonar 上看测试覆盖率等一些相关的数据。另外我们做了非常多的度量报表，也会对单元测试有一些具体的统计。 自动化测试策略，主要分四个象限，上面两个是面向业务的，下面两个是面向技术的。左边的是结果可预期，右边的是结果不可预期。然后我们会根据产品所处的特定阶段，去选择要做哪些测试，谁去做。 这是分层自动化测试框架，第一个是测试冰淇淋型，大家可以看到手工测试是占比是最多的，然后是 UI、服务测试。第二种是测试金字塔型，单元测试占比是最多的，然后是服务测试接下去是UI测试。第三种是测试橄榄球型，服务测试是最多的，其次是单元测试和 UI 测试。在我们这边，用得最多的话是测试橄榄球型。因为我们精益敏捷类的现在是接口测试覆盖率要求达到100%，单元测试覆盖率还是希望能够根据开发的实际情况来定。如果是新系统研发，我们会要求单元测试作为故事的验收标准，也就是说必须要做的。UI自动化测试的话，因为投入成本比较高，所以只要求能够覆盖核心的场景就可以了。 在分层自动化测试这块，我们不要求遗留系统补单元测试。一般是针对新增的代码，要求写单元测试。组织级在推动过程中，会发现开发人员对自动化测试的动力不足。并且自动化测试的覆盖率要达到多少，这块也是需要我们不断去探索的，所以我们现在有一个团队，他们做 TDD 的，虽然说暂时没有发现明显的质量提升。但是他们还是愿意去做一些更深入的尝试。他们考虑把覆盖率再往上提，比方说提高到70%多、80%多。然后再去看一下质量、效能是不是有切实的改进。我们组织级也是想通过开发那边具体的实践，收集一些数据，一些正向反馈的数据，然后我们才在其他团队去做推广。目前我们这边也有团队在尝试用DDD的方法来重构老旧系统，这些都是很好的工程实践。\n我们目前的分层自动化测试的策略是优先推行接口测试，鼓励单元测试。希望自动化测试，尽早的接入到持续交付流水线上去，变更触发或定时触发，每日至少跑一次。可以通过分层流水线，实现多级流水线的并行执行。建立持久的度量和反馈。 开源代码扫描，这块我们目前主要用的是黑鸭，主要是推荐 BSD、Apache、MIT 类的许可证。允许使用 MPL 类的许可证。谨慎使用 LGPL 类的许可证。不建议使用 GPL 类的许可证。 持续交付流水线是持续交付的核心实践。可以把上面说的各类实践串起来，可以串行或并行去跑。我们这边的流水线平台上支持创建各类模板，用户可以基于模板去创建流水线，也可以根据自己的需求去编排流水线的各个 STAGE，相当灵活。根据不同的分支策略，可以选择创建不同的流水线，单制品流水线或普通流水线或分层流水线。 我们都知道，代码检视对代码质量保障来说是至关重要的。所以我们这边还有一块实践就是代码检视，明年代码检视会是我们工作的一个重点。现在也在制定代码检视的一些规范和方法。代码检视方式目前主要分三种，一种是全体检视。这种方式便于知识的传播，因为每一个迭代团队大家一起检视，尤其对一些技术比较弱的，可以比较快的学到一些技能。第二种是通过PR的形式，通过合并请求，由技术骨干检视通过后代码才能交付到远程仓库，这种方式适用于异地协作模式，因为我们是三中心，三地的。尤其是近几年新员工较多，需要老员工把控下代码质量。第三种就是结对做代码检视，以旧带新。这种方式对新员工来说，提升会非常快。 这是我们内部的成熟度模型，成熟度分三级。一级包含了自动化编译、静态代码扫描、发布制品库三个工程实践。二级是在一级的基础上，增加了自动化部署。三级是在二级的基础上增加了单元测试和自动化测试。 这张图片上显示的一些度量指标，主要是我们的流水线的一些指标。构建效率，我们主要是看构建的耗时。构建次数、主要是看发布单元构建的次数。然后团队习惯主要是看是否用的主干开发，CI 频率是怎么样的，红灯的修复时间快不快。编译能力主要是看编译时间。测试完备性主要是看测试的覆盖率，测试类型覆盖。构建稳定性主要是看构建的成功率和异常构建率。其实我们现在并不是非常侧重于构建成功率，因为我们说持续集成的话，还是是欢迎大家试错的，我们现在更关注的是 MTTR，红灯修复时间。修复时间非常快，说明问题很快得到了解决，大家可以继续往该分支上提交代码。\n在编译时间这一块，我们建议不要超过15分钟，这个时长可以不包括自动化测试，比方说接口测试、集成测试和 UI 测试，包含单元测试。尤其是 UI 测试，执行时间还是比较长的，所以这个时候我们会建议用户去建分层流水线，分层流水线可以固定放在晚上去跑，第二天查看结果。 这张是杭州中心的月报图，上面会有各种关键度量数据，趋势图。我们每月发布一版，供团队和领导参考。 最后是我们 DevOps 标准认证评估分享环节。先做一个概况介绍，我们都知道招行是第一批参加 DevOps 标准认证评估的。我们在2018年的时候，就有4个项目，财富 W+，招赢通、基金、排队机4个项目通过了标准3.0的评估。今年领导也非常鼓励我们继续去参评，主要也是为了驱动内部的一些工程实践能够更好的落地。所以今年是要求精益敏捷产品，运作一年以上的，分5批参与评估，目前已经进行到了第4批。持续交付标准一共涉及7个过程域，49个评估项。我们在评估之前，会把各个参评团队的数据、情况都收集上来。然后跟依次跟这49个评估项去做比对。主要是看三级、四级、五级的能力，看差距在哪里。对于一些能够快速改进的，就马上进行整改。所以整体优化下来，对我们的推动还是蛮大的。同时，我们会发现，开发人员的潜力是巨大的。能够在短时间内掌握各种单测框架，并能快速提升自动化测试覆盖率。 从结果看，不是说开发不会写单元测试，而是他们可能更倾向于去做一些业务上的开发，所以 DevOps 标准认证对我们的推动，自动化测试这块，尤其是单元测试，我认为提升还是非常明显的。我们之前有一个试点团队，2016年开始转型敏捷，之前也有借助外部的咨询师来给他们做咨询，比方说要不要做单元测试，怎么去做，但是他们也有自己的考量，因为业务那边压得特别紧，业务希望每个迭代能产出更多的功能，而并不关注工程实践做得有多好，代码质量有多高，所以他们之前也尝试做了自动化单元测试工具，想借助自动化单元测试工具自动生成单元测试脚本、用例，但因为种种原因一直没有落地。但通过这次外评，他们很快就把单元测试做起来了，并且覆盖率还挺高。另一块就是通过外评，帮助我们找到了工具链的改进方向，目前是两周一个迭代持续优化。举个例子，评估前源代码管理工具码云上并没有代码评审这个功能，外评后，我们在上面做了代码评审的功能，并且跟 tracker 做了联动。检视出来的代码质量问题，可以直接记录在码云上，同时会同步到 tracker 对应的故事卡片上，然后可以持续跟进。流水线平台上也是，评估后，我们增加了安全扫描等，所以这块对我们推动还是比较大的。让我们知道哪些做得是比较领先的，哪些是还有改进空间的。\n互动问答  互动一：  提问1：请问，咱们招行做这个4个项目，然后我想了解在招行内部，开发、测试、运维是三个部门，还是说我们也是开发、测试、运维完全在一个团队里？\n滕乐英：我们是三个中心，三个中心是分开的，不是在一个团队里面。\n提问：那在做认证的时候，其实三方的协作会非常多在这方面有没有遇到一些阻碍或者困扰？\n滕乐英：其实还好，因为我们现在已经平台化、工具化了。很多实践都是通过流水线去跑的，并且我们有度量平台，可以用数据说话。我们内部也有技术教练，不同技能的技术教练会负责跟进不同的问题。最关键的是，大家都比较重视，所以总体来说还好。\n提问：您刚才展示的工具确实特别多，我想知道这些工具是完全做到端到端打通了还是说工具之间其实还是孤岛，有没有哪一项是孤岛存在的？\n滕乐英：工具和工具之间有 API，相互之间可以调用。我们后续计划是起个项目，会把这些工具全部整合到一个平台上去，这是我们明年计划做的事情。\n提问：需求管理，用的是 tracker么？\n滕乐英：需求管理，其实分两块，因为我们行内是双模的，有传统的，有走精益敏捷的，所以需求管理，传统项目的是放在 VP 里面，精益敏捷的是放在刚才介绍的 tracker 上，这是我们自己分装的一个工具。\n提问：认证的4个项目，全是基于敏捷，还是说也有您刚才说的传统的也有？\n滕乐英：参评的全部是走敏捷的，传统的不参评。\n 互动二：  提问2：请问，刚才你讲的测试，好像没有涉及到 UI 自动化测试？\n滕乐英：有涉及的，我们 UI 自动化测试，会侧重于测核心的一些场景。\n提问：工具用的是什么？\n滕乐英：主要用 Robot Framework，通用模拟器。\n 互动三：  提问3：请问，在测试数据管理方面，有没有实践？\n滕乐英：测试数据管理，一块是生产数据脱敏，有些数据还是比较难脱敏的。所以另外一块是通过工具自动造数，很多团队都会用工具去自动造数。\n提问：你们内部有这样的工具吗？\n滕乐英：对，我们内部有这样的工具。\n提问：大概是什么原理，可以简单介绍一下吗？\n滕乐英：开发、测试人员会编写一些脚本自动化生成测试数据。\n提问：有一些数据是测试人员自己造的？\n滕乐英：是的，测试人员会造数。\n 关于作者 滕乐英\n招商银行\n杭州研发中心\nDevOps 推广负责人\u0026amp;技术教练\n在招商银行工作14年，由开发转型做配置管理、DevOps，参与招行 DevOps 持续交付流水线平台的建设、推广，及 DevOps 标准认证评估工作。目前主要负责杭州研发中心及分行的 DevOps 持续交付实施与推广，并兼任行内精益技术教练一职。\n","permalink":"https://devopschina.org/blog/the-devops-practice-and-standrad-certification-assessment-sharing-of-cmb/","tags":["DevOps","标准认证"],"title":"招商银行DevOps实践及DevOps标准认证评估分享"},{"categories":["演讲"],"contents":" 本文内容选自中国 DevOps 社区年会 · 2019年会，乔梁老师分享的《 DevOps 之十倍速原则》实录。\n 大家好！很高兴社区能邀请我来杭州参加这个年会。我来杭州应该是上个月来过一次是在云栖大会，讲了类似的 topic，不知道有多少人去。在过去十年里，在连续十年 QCon 大会，我每年的 topic 和内容都不同。但从今年年初开始，我打算把这个 topic 重复讲几年。只有重复不断的讲，才能让人记住。\n介绍一下我自己，我叫乔梁，在IT行业有很多年了，已经老到不再写生产代码了。这是与我相关的几本书。2009年我在 Thought Works 工作的时候，翻译了《Thought works文集》，我认为其中大概有5、6篇文章所讨论的方法，对目前80%团队仍旧非常有效。尽管在当时，“敏捷”就像现在的 DevOps 一样，开始广泛流行，但是，根本没有几个团队做得好。现在大家就开始做 DevOps。我想，从今年开始，DevOps 也应该进入一个平台期了。\n2011年的时候，我翻译了一本书叫《持续交付》我称它为 “持续交付1.0”。当时我找了国内很多出版社，希望引进这本书，但很多个出版社并不看好它，几乎都拒绝了我的要求，说这本书不好卖，受众太小。我心想：”不管能不能出版，我先把它翻译了再说“。所以，我自己向作者 Jez Humble（也是我的同事和朋友，我们在同一个项目组）要了英文文档。当翻译到一半的时候，终于找到一个出版社，这本书才能顺利出版。也许，这个是国内IT领域翻译的最快的一本书，我只用了8个月时间，基本上占用了我所有的休息时间。\n最近十年，我一直从事相关领域的咨询工作，中间没有间断。2017年，我决定把我的经验与心得写下来。于是有了这本《持续交付2.0》。这个副标题”业务引领的 DevOps”，也是我多年来的思考。一切皆是业务引领，所谓的技术驱动也是业务引领的结果。很多人认为，敏捷开发就是就是IT部门的事情，但实际上任何一个组织想要做好，都不是单一部门的问题。现在，大部分组织中的IT团队都还有一点儿“技术外包团队”的味道，在 toC 互联网企业可能会相对好一些，因为它有个特殊的优势，就是它的软件产品就是企业命脉，这个命脉正好和IT技术相吻合的，所以这也是为什么现在的很多软件工程方法都来自于互联网公司的沉淀。\n说到“业务引领“这一点，我就要提一下硅谷的这两位大佬。一个是做电商的贝佐斯，一个是做社交的扎克伯格。但是几乎使用同一种方法，来发展各自的公司，这个方法就是“一万次实验法则”。\n大家都知道“一万小时定律”，一万小时定律是针对个人技能修练的方法。而在一个快速变化的商业领域里面，一个组织如何应对变化，如何找到先机，这个定律是不二法则。而这种能力，通常是传统软件公司不具备的能力。这种业务快速尝试的诉求，必然就会导致原本作为支撑团队的 IT 部门必须想到各种各样的方法，建立各种各样的软件基础设施，来支撑“一万次实验法则”。\n他们为什么会有“一万次实验法则”的说法？以 Facebook 为例。Facebook 公司内部经常提到的一个词是“Data Inform”。是的，你没有听错，不是“Data Driven（数据驱动）”，是“Data Inform”。它提醒我们，不能成为数字的奴隶，但是一定要掌握数据信息，为自己的判断提供依据和佐证，或者用于深入了解用户。\n《持续交付2.0》是指从端到端交付业务价值的角度看待组织能力的提升，而不仅仅是软件的交付。它强调端到端的交付业务价值。这需要组织中各种角色之间能够打破部门墙，角色墙，建立一些新型组织。我这里要提醒大家的是：虽然大家都说“我们打破部门墙”，但目前看，人类社会中是不可能没有“墙”的。因为人是社会型动物，无论如何时都需要某种组织形式，人们需要身份识别与身份认同，以及群体归属感。当拆掉一面“墙”的同时，也在建立另外一面“墙”。\n在《持续交付2.0》这本书中提到的双环模型与 DevOps 标记所指的范畴不同。不同点在于，左手边的环更多倾向于业务价值探索，而并只不是“Plan”，它具有高度不确定性。在高度不确定性的条件下，如何发现那些确定性的方式、方法，找到其中的一些确定的点，能够快速实施，这就是价值探索环的意义所在。\n这个价值探索环一共有4个步骤，它们4个步骤之间并不是一个完全的单向顺序关系，实际上可能是双向反馈关系。在价值探索环完成了第4步“选择精炼”时，通常就进入了传统 DevOps 和持续交付1.0所涵盖的内容。这一部分基本上可以被认为是一个“相对确定性”的过程，因为你已经明确地知道你要做什么。如果此时你还不知道确切要做什么，说明你还没有准备好。而现在我们行业里面，基本上都处于没有准备好就开始干的状况。\n进入第二个环后，我们追求的是“工程卓越”，通过我们工程技术的手段快速实现，高质量的交付，最终能够快速的拿到数据，从而与第一个环中“锚定”的目标对比，用于验证“提问”的问题。\n今天，我也不会讲特别多关于价值探索环和业务创新的内容，而是讲“工程卓越”。\n如何追求工程卓越，我认为可以从以下三个方面进行：工作流程、支撑工具、工程素养。此时，所有的改进都可以围绕这三方面来去实施。大家一看“流程、工具、人员能力”好像千篇一律。但是，我今天想讲的一个要点是：“我们之前在制定工作流程，建设支撑工具的时候，一个最大的出发点是匹配现有人员的能力去做出对应的工作流程和支撑工具。恰恰是这一点，让我们的软件工程基本上十年没动。真正行之有效的方法是：流程与工具不应该适应现有的人员和组织能力，而是要稍高于它。”如果三者恰好匹配，说明组织及组织中的人正处于舒适区，而不是“学习区”。\n作为一个组织，当你去制定流程和工具的时候，一定要稍稍超出你现在现有人员的能力，而不是适应现有人员的能力。\n关于工程素养我只是简单地讲一讲，后面熊节也会分享他的想法。今天我主要讲前面这两个，就是对于组织如何去思考工作流程和工具。我认为，组织应该考虑采用“十倍速原则”。作为一个组织，一定会追求更高的效率，更高的目标来实现业务增长。而定义流程，制造工具需要思考的是，未来3个月组织应该是什么状态运转，未来6个月呢，未来一年呢？十倍速原则正是一种思考方式。要想达到“一升汽油让汽车跑500公里”，在现有汽车设计上，一定是不可能的。必须想其它办法才行。也就是说：当你设定一个远超现状标准的目标时，你就需要去重新改变你的结构来找到一些新的方法达成，现有方式是不可能达成这种挑战目标的。这个就是我今天的主题：“十倍速原则”。\n当然十倍速原则本身是挺简单的过程，要持续的实现十倍速原则是一个非常痛苦的事。下面看一小段魔方的视频来理解“十倍速原则”。前面那个是我自己拧魔方的时候，大概是26秒，不是我的最好成绩，我在“刻意练习”。中间那位是世界记录创造者，大概4秒多就可以复原三阶魔方。我还不会玩魔方的时候，我就想达到30秒以内。找到了10个公司，记住，练习，每天大概练4、5个小时，1—2周你就可以达到大概40秒左右，做到“十式走天下”。\n再想提高，可以继续练，但提高很慢。而且无论怎么练习，都不会达到20秒。所以必须换方法。这才有了“119式“的练习。因为119式是右手公式，我是左利手，所以速度再想提高，可能就要创造方便自己的左手公式了。所以，简单重复无法提高，只有刻意练习才行。而“刻意练习”也有瓶颈，必须改变模式才行。\n所以，做同样的事情，不同的流程、不同的方式、不同的制作工艺，会产生不同的结果。如果你想达成十倍速原则，你不可能一直沿用现有工作模式。而目前所有研发管理都还沿用传统模式，基本上没有改变。所以说，中国软件行业十年基本上没有什么变化。\n关于工作流程的改变，我讲一个例子，大家会更加深入的理解。2013年，我到一个大约400多人的团队，负责一个 PC 客户端的互联网软件，去帮他们改进软件交付模式。在当时，他们原定的计划是：每年12次发布，每个月一次。每月的前3周进行版本开发，最后1周进行测试，然后就发布了。我估计现在有很多团队都是按照这样的模式计划的。\n不幸的是，他们无法按照这个达成计划目标。他们的工作基本是这种状态：前面三个星期都在开发，到了开发阶段的最后一天（马上到提测时间点了），开发人员还没有可以提测的软件包呢。这时怎么办？开发人员迅速把他的代码提交到代码仓库，然后匆忙打一个包给测试人员，并说：“你们可以开始测了，赶快测吧，有 bug 我们就修”。然后就是一轮一轮的集成测试，然后不断地发现 bug。到了最后时间点，老板说：“必须把x需求加到这次发布中！”为什么一定要要在这个发布中呢？因为如果这个需求无法进入这个版本的话，它要再等一个月，才能与用户见面。\n那么，请我去指导的目标是什么呢？就是达成这个团队的原始目标：每个月准时发布一个全网版本。现在团队已经有一整套工作模式，并形成了非常稳定的模式。如果只是在此基础上改进，很难在较短的时间达成目标，并能持续保持下去。而且，不断重复原有的一贯做法，只会得到与以前一样的结果。只有达到远超要求的水平，才能轻松实现被要求的结果。所以，必须彻底改变现有的工作流程模式。\n最后，目标是做到三个“1”，即：\n（1）每个月都要有一个正式版本（全网版本）\n（2）要想达成（1），我们就要每周发布一个 Beta 版本（要有200百用户试用）\n（3）而要想达成每周一个 Beta 版本, 就要每天能够发布一个 Alpha 版本（要有50万用户）。\n原来的组织是按职能划分的，产品、开发、测试，有各自独立的部门。每个版本在同一时间点启动开发，在指定的时间点统一提测。我们做的一件事情就是流程再造，即：改变团队协作流程。另外，也对软件架构做了改造。整个组织的运行模式如图所示。整个团队被分成几个子团队，每个团队有自己的运作节奏，而整体版本也有整体版本的节奏。这样，我们可以实现，每个功能完成都可以随时发布出去，验证功能反馈，部分实现了持续交付。\n这种运作模式带来了一个原来根本不存在的问题。原来的模式中，每个月才发布一个版本，现在每个月发布数十个版本。如何高效地管理这些版本。作为技术人员，就要去找到一些方式或方法解决这类技术问题。从这一点可以看出，“十倍速原则”的应用一定会带来前所未有的挑战。而对于应用“十倍速原则”的团队来说，这种挑战不再是一个可选项，而是必须完成的任务。\n在这个组织中，很多人第一次看到这样的运作流程时，首先想到的是“这个很难，基本上是不可能的”。然而，最终我们花了4个月的时间，还是做到了。4个月之后，基本上可以保证每天可以发一个 Alpha 版本（甚至两个），所以每个月底发一个正式版本，就不再是个问题了。\n当团队达到这一状态以后，突出问题不再是交付问题，而是业务成长问题。原来的业务成长问题被所谓的“交付问题”所掩盖。现在交付不再成为瓶颈以后，我们发现业务想法的靠谱度成了主要矛盾。当然，这里不展开这个话题，它与刚才讲的持续交付2.0双环模型的第一个环有强关联。\n流程的改造，必然会带来一些冲突需要管理。最显而易见的冲突就是：\n**第一点：**不同团队的发布时间的冲突，以及发布质量的冲突。每个团队都有自己开发的节奏，但是，作为组织级的一个大产品，必然要管理各个团队的时间与质量，否则的话就会互相影响。怎么来做管理冲突和管理质量呢？\n我们也应用了“十倍速原则”。搭建了一个工具平台，管理所有代码，包括代码的合并、代码的分支，所有常见操作都不需要开发人员操心，只要遵守规则，工具平台就可以把这些事情做完。当然这些规则就会改变开发人员的行为。为什么团队成员要遵守这些规则？因为这些工具平台为团队员工提供了非常方便的工作方式，减少他的工作负担。在这一点上，是很多企业内部工具团队做得不好的地方。如果只是给他们定流程，定规范，但是你不能让他的工作生活变得更美好。那很可能会受到开发人员的抵触。\n**第二点：**关于“管理质量”，我们就选择了可以说是“非常简单粗暴”的原则。这个大团队被拆成了多个小团队之后，每个小团队要负责自己的软件质量，同时也负责自己的业务目标。而我们的原则就是：如果你的交付在Alpha版本质量不达标，那么就禁止你在Alpha版本中加入自己新开发的功能，直到修复原来的质量问题，并达到标准。由于，每个团队都有业务目标，如果不发新功能做试充分，就很难达成业务目标，所以，每个小团队的产品人员、技术人员都会非常关心产品质量。\n事实上，这种改进并不是无迹可循。在《持续交付2.0》一书中，我总结了“持续交付七巧板”，我讲的这些内容都在其中有所体现。例如，本案例中，最开始的时候我们做的是“软件架构”这个版块。为什么是“软件架构”这个版块？因为没有进行改造之前，版本项目经理制定项目计划，规定了提测日期和时间点。如果在这个时间点，有开发小组无法合入代码，打包提测的话，开发组长就要缴罚款。最开始是10元，不行，还是做不到！那就20，还是做不到！50，还是做不到！甚至有的开发组长在计划提测当天的早上就把50块钱准备好，交给版本项目经理了。从这个小事上，我们也可以看出，瀑布开发模式下，大版本的最后集成提测有多难了！软件架构不清晰，互相耦合太严重，技术债务太多。因此，我们先做了软件架构的解耦。然后做了团队解耦。当然，七巧板中的基础设施部分一直在不断改进。\n流程的改变，势必影响到工具建设。我认为，好的工具平台要满足下面三个要求：它们是标准化、高要求和简单易用。很多企业内部负责软件工具平台开发的团队，都最先强调标准化。其次是高要求。即对开发人员的日常工作行为提出更高的要求。当工具满足这两点以后，做到“简单易用”就非常难了。\n举一个工具建设的例子。Bazel 是 Google 很早就已经开源的一个 C++ 构建工具。这个构建工具支持很多种编程语言。所以，在 Google 开发人员基本上不需要了解不同语言的构建方法，使用 Bazel 统一描述语言即可。这让团队成员在团队之间换岗时根本没有这方面的学习负担。\n这样的标准化之后，开发人员的负担就轻了。而且，Bazel 的一个优点是：依赖管理做得非常好，因为它只允许单一依赖，如图所示。你可以看到非常清晰的单向依赖拓扑图。这个好处是什么呢？\n**第一个场景：**当修改了图中最下面一个基础组件的时候，Bazel 就知道它会影响上面所有的组件，因为运行自动化测试时，会自动运行所有的自动化测试用例。\n**第二个场景：**当仅仅修改了其中的一个组件，例如 youtube Client，Bazel 就不会运行所有的自动化测试用例，而只是有针对性地运行那些受到影响的组件自动化测试用例。\n十倍速原则下的收益，就是通过巨大的改变，完成那些看上去不可完成的任务。通过流程再造，消除原有流程中的很多浪费，让你有更多的时间去做有价值的活动。对于软件开发这件事情什么是有价值的活动？把语言变成代码是有价值的活动，其他的都不是。\n这张图截到自网上的一篇文章，它提出了一个很好的问题：“为什么 Google Bazel 这个构建工具流行不起来？”是因为我们的软件项目比 Google 的项目更复杂么？我想，不是的。因为使用这个工具需要非常强的纪律性，它有很大的约束。如果管理能力没有达到，的确很难应用起来。但我们不就是要不断提升我们的管理能力么？\n事实上，Google 在2005年的时候，和现在在座各位的组织在软件项目管理上没有太大的区别。只是它在很早的时候就意识到了这一点。从2005年起，开始进行工程效能方面的变革。他们认为，释放开发人员的能量是最为重要的，所以会有这样的工具出来。\n由于时间关系，我简单讲一下工程能力与素养。\nGoogle 对代码的要求很高，国内对代码要求很高的公司不多。Google 工程生产力的三个支柱分别是 Code Health、Debuggability、Infrastructure。你可以明显的感觉到，国内公司对这三项是基本不强调的。\n举个最简单的例子，就是 Code Review。Code Review 是公认非常有价值的活动，但是在国内基本上就没有实行起来，为什么？因为我们根据我们现在的情况，只有重要的需求才做 review，紧急的情况时不做 review，各团队规范不一致。\n然而 Google 每行代码都要 review，代码规范全部一致，必须具备可读性。\n我们在自己的代码库中经常见到大量复制/粘贴的，无法写出自动化测试的代码，随处可见。\n最后，再提醒大家，在 DevOps 建设中，一定要当心“烟斗曲线”。无论是敏捷也好，还是 DevOps 也好，都会 follow 这个“烟斗曲线”。是这样走过来的。敏捷实在搞不下去了，现在又开始搞 DevOps 了。\n这个烟斗曲线是指什么呢？大家都说：我们要选一些简单的，能够快速上的改进活动。比如敏捷开发中的站会，故事墙等。这些事情在刚开始会有一些作用，但作用有限。\n我们以自动化为例。最开始做工作流程自动化，大家纷纷上了 Jira，jenkins。然后，测试团队开始写自动化测试了~为什么呢？因为开发人员都不写自动化测试。因为他们认为测试是测试人员的事情。而测试人员不想一遍一遍的手工回归。最开始写自动化测试用例，初期没有太大的成绩，当达到一定数量以后，至少冒烟自动化测试有了以后，可以在开发人员提测时拦截一下。\n此时，领导会给时间积累一些测试用例。积累到一定的时候，比如说测试用例达到2000了，这个时候会有一些稍微明显的效果。此时，会加大这方面的投入，增加更多的自动化测试。当你以原有方式增加更多的自动化测试以后，你就会发现，自己到了平台期，即：投入多，效果并不明显。这个时候老板就对你失望了，然后你自己也坚持不下去，然后就跑到那个沟里了，基本上是这样一个状况。\n其中常见的一个问题，测试人员写的自动化测试通常是集成自动化测试，从 UI 层驱动的自动化测试比较常见。这些用例并不稳定，经常是“随机成功”。测试人员很大精力都是在维护这些“随机成功”的用例上。要想突破，做得更好，一定要应用“十倍速原则”。挑选容易做的事情进行改进，当然没有错，错就错在只选容易的做，而且一直做。这一定是错误的。因为，组织此时仍旧是在自己的舒适区中行动，并不会有真正的提升。\n最后，总结一下“十倍速原则”在 DevOps 方面的应用。\n流程方面：以终为始，具有颠覆性才能有大的飞跃。\n工具方面：高标准下的简单易用，才能创造更大价值。\n能力素养：有了时间，才能学习，提高工程能力与素养。\n互动问答 提问： 您刚才说那个测试，测试是集成测试还是单元测试？\n乔梁： 我见过有些测试团队试图写单元测试。我认为，这么做是错的。单元测试就是应该由开发人员来写，而不应该是测试人员。\n提问： 所以我的问题是：您刚才说的2000个测试，测试人员写的是单元测试还是集成测试？ 乔梁： 我的例子中是指集成测试。\n提问： 集成测试本来就应该他们写，没有问题。 乔梁： 但是，写的不好，没有能力写好，这就是问题了。这个不是应不应该的问题，而是能不能做好的问题。很多领导说：“你就应该做……”，但是，如果不具备相应的能力，赶着鸭子上架，最终导致结果也不会太好。\n关于作者 独创双环模型与组织文化四步法。DevOps 领域顶级大师，国内第一位持续交付布道者，率先于2010年将DevOps和持续交付相关理念、原则和最佳实践引入中国，并辅导华为和百度进行实施。\n目前作为腾讯外聘高级管理顾问，指导多个事业群的产品研发管理工作和相关工具平台建设。同时，为多个（toB 和 toC 领域）移动互联网公司提供组织管理咨询服务。曾辅导过亿注册用户量的互联网产品十多款。曾作为敏捷\u0026amp;精益组织转型导师，就职于 ThoughtWorks、百度和 Nokia。\n","permalink":"https://devopschina.org/blog/ten-times-speed-principle-of-devops/","tags":["DevOps"],"title":"DevOps 之十倍速原则"},{"categories":["演讲"],"contents":" 本文内容选自中国DevOps社区年会 · 2019年会，王立杰老师（无敌哥）分享的《打造信任、尊重与担当的DevOps文化》实录。\n 大家知道古代有一句话叫大军未动，粮草先行。这背后是什么概念呢？实际上是说我们做什么事都要有所准备，粮草是行军打仗第一个要筹划的事情。今天我把这句话稍微再调整一下，我改成DevOps转型未动，文化要先行。\n今天这个题目其实来自于一本书《敏捷无敌之DevOps时代》，这本书的其中一个目录就叫“DevOps文化：信任、尊重与担当”。这本书其实是我跟姚冬老师，还有许舟平老师，我们三个人一起合著的一本书。把我们每个人将近二三十年的经验，融合在一起，经过多次碰撞，才产生了这么一本书。当然它是一本小说，茶余饭后看一看、边娱乐边学习。\n到底什么是文化？可能大家对这个认知不一致，一般我们说一个人是有文化的，他要懂琴棋书画，会讲诗词歌赋。但是大家要知道，我们所提到的文字，大概在人类也就存在3000年、5000年而已。历史发展这么久，文化肯定不仅仅是指这些。有很多人对文化有解读，这里面我特别喜欢王东岳老师在《物演通论》里面的一段解读。**他说文化就是人类为生存所逼迫，所产生出来的思维方式与行为方式的综合。**这段话背后有几个关键点，第一个他讲到的是生存结构，也就是说所有文化的产生都是有外在环境所逼迫，从而影响你的生存方式。另外一点因为自然环境不同，从而影响到了我们如何去思考，如何去对待它。所以我们经常讲“一方水土一方人”，“靠山吃山，靠水吃水”，其实都是在讲生存结构的问题。\n我们经常讲文化是有延展性的，可以很容易的扩张到其他方面。但很多时候，我们忽略了文化的另外一个关键点是文化的遮蔽效应。文化的遮蔽效应是什么概念呢？让你看不到你该看到的一些东西。文化为什么会有遮蔽效应？是因为每个体系它在生存、发展、思维的变动过程中，它一定是体系内恰，体系内恰的东西，它的逻辑性太强了，就会产生遮蔽效应。\n接下来我们再来看一下我们对企业文化的一个定义。这是来自于搜狗百科，从这个定义里面，我们可以看到它是跟组织的价值观、仪式、符号、处事方式等有关，而且是在企业在日常运行中所表现出来的各方各面。\n每个人对一个事物有认知，通常来讲自己很难打破认知遮蔽，从而形成每个人自己的心智模式。组织也有组织的心智模式，组织文化的遮蔽效应，通常来讲会对任何变革产生阻碍。\nDevOps转型的第一个要素就是改变我们的文化。不同的大师对DevOps的原则是有不同的概念。最早提出的是CAMS就是文化，Culture、automation、measurement、sharing这是John Willis。后来Jez Humble觉得说我们少了一个，我们要快速交付，要流动起来，所以提出了精益Lean。再后来SAFe的方法论专家们认为在规模化敏捷框架下，推动DevOps落地的时，提出来一个Recovery。觉得我们要快速上线，你不可避免的会产生一些错误，产生错误的时候我们要能够具备一种能力，向前修复或者向后修复。反正是需要快速恢复。我们在度量的时候也经常会讲一个指标叫MTTR，平均故障恢复时间。所以Recovery非常重要，把这个原则单独列了出来。从另外的角度讲，文化本身就应该是开放的，应该是支持共享的，所以就去掉了Sharing，认为这应该是文化的一部分。但各个大师们无论怎么讲，都是把文化这件事情放到了第一位。\n为什么文化变革很难又如此重要呢？相信大家都吃过海底捞，海底捞的火锅非常好，很多人也在模仿。但是大家可以看到，不同的餐饮企业只是模仿了一些表皮，很难再造一个海底捞，也或者是说你模仿海底捞的那些服务。但没有找到海底捞背后最根本的东西，其实它有一种企业文化\u0026mdash;-以客户为中心，为客户提供最好的服务。海底捞这个企业很奇怪，他说你可以到我的公司参观、来看，我也举办学习班你也可以学，但你就是模仿不了！所有，有人又写了一本书，叫《海底捞你学不会》，就是你学习了表象，但文化没有改变，你学到的都是表层的东西。所以我们今天同样在讲DevOps，讲DevOps的转型，一定要从文化转变做起！\n这些年DevOps不断演进，我们已经从传统的D2O（音）已经扩展到E2E，即端到端的这样一个DevOps。端到端的DevOps意味着什么？大家看右侧这张图，我们从用户真实的需求出发，经过我们的开发测试，再到我们的部署，以及整个持续交付和最后监控上线的端到端过程。在这个过程中我们需要有很多的持续反馈环。\n为什么我们要往推到前面的创意那儿呢？很重要的是需要跟我们的业务去结合。为什么业务如此重要？因为业务决定了我们企业的生存，每一家企业，每一个产品线，可以说都是一个生命有机体，每一个生命有机体一定会经过生老病死。所以这里面，也就是我们经常讲的，每一条生命曲线里面有一个极限点，在达到极限点之前会有一个倍速的增长。如果你的整个研发能力不能够支撑你倍速的增长，那么可想而知，你会错过很多机会。\n同样在到达极限点之后，你要发现第二条曲线的时候，又需要做创新，我们讲DevOps需要支撑我们快速创新，快速验证，快速试错的一种能力。但是这个如果你不具备，但是很不幸，你有可能跨不了第二条曲线，所以企业有可能会衰弱。我们今天讲DevOps转型，一定是跟你的生存结构相关，很多企业在整个DevOps推动落地的过程中，从他的业务发展路径上来看，都是非常贴合这个演进路径的，我们后面看案例。\n我们知道在企业内经常会存在特殊的人，我们称之为“懒蚂蚁”。什么意思呢？在生物学中经常提到的一个“懒蚂蚁”效应。蚂蚁这个群体大家都知道，它很多，量非常大。通常是数十万、数百万的蚂蚁聚集在一块生存。他们到了一个地方，很快就有可能把一个地方的资源耗尽，资源耗尽的时候，蚂蚁就没有了方向。但是在蚂蚁群内经常存在一些懒的蚂蚁，经常不干活，也跟大家不一致。他们就是在四处的游荡，然后帮大家去发现新的资源。当整个蚂蚁群的整个资源将要耗尽的时候，他们会站出来告诉大家说那边有新的资源，我们可以往那个方向前进。对于企业来讲，业务创新、产品创新、孕育企业第二条曲线，同样需要“懒蚂蚁”的存在。我们把这些“懒蚂蚁”称之为企业内懒于杂物，勤于动脑的人。如果允许这些人存在，你的文化一定是有包容性的，要有信任、担当。\n业务要快速适应外界的变化，我们经常讲，“要让听见炮火的人发出指令”。这意味着我们需要给一线的人，真正懂得市场的人授权，让他能够自治。但是仅仅授权也是不够的。就像右下角这张图：授权太大，每个人都很自由、开心，但缺乏了方向的一致感，整个效率与效果，包括未来成功的可能性会大大降低。我们特别期望大家真正达到的是什么？既要有自治，同样要有高效的对齐，就是右上角这个图所展示的效果！\n这个过程中，同样离不开我们对文化的改造。接下来我给大家讲几个案例，看这些公司在他们演进的过程中，如何通过文化的改造与改进，从而实现了DevOps的转型。\n我们先来看微软。微软大家都很清楚，微软是PC时代的王者。在windows时代，微软是王者，那时我们的商业节奏也很慢，大家开发的周期也很长，没有关系。但是到了移动互联网时代，也就是鲍尔默时代，却没微软什么事了。微软在移动互联网时代的操作系统不work。这里边所以微软很快有一个衰弱期。但是最近到了纳德拉时代，微软又再次重生，因为他又抓住了云。这个过程中是你会发现，他的业务这条线在跨越，在不同的几条曲线内跨越。这个过程中是如何演进的呢？\n我们先来看鲍尔默时代，在鲍尔默时代，微软其实是有一种封闭、傲慢、反协作的一种文化。其实大家可以看下面这张图，相互内部的管理部门之间，是不合作的互相拆台的。在这种文化下，我们讲DevOps要跨部门的，端到端的打通有可能吗？非常难。\n所以纳德拉其实曾经这样评价过鲍尔默，“就是你提出一个想法，他总会说这是我听过最蠢的主意，或者说我根本不同意，要对付他你必须坚持不懈。”所以这么一个人是非常固执，非常保守的一个人，所以整个人公司的文化也是崇尚这种精神。最终的结果是什么样呢？\n最终的结果，所以微软以前我们经常称之为大瀑布时代。做什么项目都周期非常长，像这个Vista，花的周期非常、非常长，但是却是微软历史上最短命的一个操作系统。可能很多人都没有用过Vista的操作系统。刚才也提到了移动互联网时代，你要快速的适应用户的需求，快速的迭代，但是微软根本就快不起来。所以在业务上你是支撑不了转型的。\n**纳德拉要做的一件事就是是刷新微软的文化，他想把一种固化型思维，改变到一种成长型思维。**因为这个成长型思维，我们要更多地去试错和包容。怎么做到的呢？\n他首先修改了微软的使命，当然直接改不太合适，所以他把比尔盖茨请出来了。跟比尔盖茨一块来修改比尔盖茨当年提出的使命，因为那个使命早就实现了。所以他要把使命变得更大，从而激发微软有更新的方向。做了这件事情之后就行了吗？使命就是一句话而已，修改最简单，但是最重要的是你亲自把它推广下去。\n所以纳德拉，他真的是很了不起的CEO，他真的是以身作则，敢于承认自己的错误。最知名的一个错误，就是关于一个女性论坛，他说了特别不恰当的话，说完之后他也很后悔。一般来讲，很多人是CEO要维持高大的形象，他说不行，我既然错了，我要跟所有人表达歉意。所以他内部发信，让所有员工都要去看。而且接下来还干什么？跟所有人开会讲，我当时说的是非常抱歉，非常错误的话。所以这是从上到下在做一件事情。\n另外一个在对外的层面上，他的真的开始做到开放。以前来讲，微软和必应（音）搜索其实是有协议的，独家绑定。但是人家说我这个要修改一下，在以前来讲微软是绝对不允许干这事的，要么打官司掏钱。但是纳德拉说没问题，我们允许修改。这其实也体现了你的自信和开放。所以后来微软开始拥抱Linux，一块儿跟开源社区去发展。\n正是通过这种文化的refresh，微软才不断的体现了内外的协同。比如我们讲DevOps，一直在讲跨部门的打通。这里面有一些案例，在第一个里面就是讲的No Silos打破筒仓，如果没有打破筒仓的协同，你整个企业对外来讲就不可能表现的像一个个体一样，端到端的交付，为你的客户提供服务。当然快速迭代、试验，这是它后面自然而然达成的效果。关于微软案例的详细解读，或者内部的一些东西，大家可以下午再去听听许徐磊老师的分享。\n我们接下来再看另外一个案例叫Amazon，Amazon提倡的是主人翁意识和试错文化。\n这是Amazon的业务发展过程，也就是它的生存是逐步如何演变的。最早就是卖书的，从卖书的单一品类扩到综合性电商，再从综合新电商变到他现在所谓的云的概念，再到他的Prime。所以他现在有三大业务板块电商、AWS和Prime。当然还有很多其他的一些尝试，包括他做的手机，Kindle等，有些成功了，有些不成功，但就是在不断的努力。从业务演进过程中，我们来看，他一直在倡导的是什么？\n贝索斯每年都会给股东写一封信，这是我罗列了几封信。在每一封信里边大家可以看到，关键字是以客户为中心。为什么他要这么做，其实还是在电商领域，特别强调的是用户的体验。如果你强调用户体验，就得把用户放在中心。\n所以他在2000年前后，就开始打造这么一个飞轮。飞轮里面最核心的是以用户为中心。如何以用户为中心是要三个要素：1.给用户更多的选择、2.更低的价格、3.更快速的交付。如果实现了这一点，客户体会体验提升，客户的体验提升，就会带来更多的流量，更多的流量就会带来更多的卖家，更多的卖家接下来就会降低整体的成本，实现边际效应。所以飞轮一旦打造成功，它的业务就会飞速成长起来。\n但是打造飞轮肯定不容易，飞轮的高效运转，一定离不开IT的研发支撑，所以他在2002年就开始DevOps的转型。贝索斯在内部发信，最早讲他所有的服务就是要转向微服务，当时不叫微服务，叫SOA（音）。其中第六条大家可以看，如果你不遵守规定就开除！\n从上到下，这就是他们被生存所逼迫，做不到这一点那么你就离开。他的整个核心价值观里面，一定是在提倡主人翁、创新、行动这些都是非常难得的东西。他还设了放手去做的奖项，就是鼓励大家去折腾，然后去做一些创新的事情。刚才我们也提到了蚂蚁，在亚马逊里面会有很多的“软蚂蚁”。\n接下来我们再来看看Google，Google做了哪些事情呢？\nGoogle非常重要的就是授权。Google的自治是怎么做到的？很重要就是把管理者的权利放到笼子里面。具体的举措有哪些呢？我这里面随便罗列了一些，譬如说雇佣谁、评价谁、如何加薪，如何升职，这通常不是你的直接manager说了算，他是要有另外一个机制来决定。\n在整个公司内会消除地位特征，做很多决定不是靠你的感觉，更多靠的是数据，真正拿数据来说话，所以我们讲这个度量就非常、非常重要。给员工授权，让他们去做自己能做的事情。你会发现真正放手去做之后，员工的表现是远远超过你的预期。Google也提倡20%的自由时间，这个是非常重要的，因为我们需要大家有这种责任和担当的一种文化。\n我们再来看另外一家公司，Netflix。\nNetflix强调的是自由和责任。他如何实现自由和责任？在整个Netflix发展过程中，他们早期其实文化也不是这样，文化是如何改变打造出来的，也是跟随自己业务的调整不断进行的。最早他就是租赁DVD的，还是邮寄的。后来这个业务肯定不符合趋势啦，后来他又转型到线上的流媒体业务，但是在帮别人卖东西，帮别人赚钱，自己却赚不了太多钱，都是辛苦钱。所以在2013年开始做原创，卖自己的产品和内容。现在好像有一个新的预测，大概应该到2022年，他产生的原创内容会超过整个好莱坞，是非常厉害的。在整个增长的过程中，他也需要自己的IT服务进行相应的升级去变化。\n对于C端提供的产品和服务，必须也是要强调用户体验，尤其是在线媒体的播放很重要的东西就是在于说你基础设施的稳定性，虽然它已经架设在AWS上，但他依然觉得AWS不够，我们需要在AWS做一个深层的包装，所以他们在内部会有很多的工作方式。其中有一个大家可能最熟悉的就是混沌工程（音）。混沌工程（音）其实是由一帮猴子来造就的。他在工作日内，有一些员工专门设计一些程序，或者做一些意外事件来把系统个瘫，从而来看我们整体的反应能力和快速修复能力。所以他的猴子里面会有捣乱猴子、看门猴子、医生猴子、一致性猴子等等，组成了猿猴军团，从而实现了技术上的反推。他在技术上达到反脆弱能力之外，还有个非常重要的业务反脆弱。所以来讲他又做到了简单、透明的业务模式，把它更简单以支撑业务的时效。时间关系，我们不展开啦！\n另外一个就是在组织层面上去做很多的操作。在组织层面上，我们只提一条，“我们只招成年人”。什么叫成年人？成年人不是说你的生理年龄成熟，最重要的是心里成熟，心里成熟就是能够对自己的行为负责，有担当，有责任感。有了这种东西，你再加上一定的授权和支撑，自然就容易实现很多的改变。这就是为啥我今天的题目要这样设定的原因，时间关系，我也不展开。\n我们再来看另外一家公司Etsy。\nEtsy这家公司很奇怪，我们国内大多数人可能都不知道这样的一家公司。这家公司也不是特别大，但是很有名。他们是做什么呢？专门做工艺品电商的，是个小的细分品类。在这家公司里面，他们提倡的文化有几个关键点，代码就是工艺品，关注问题不指责。\n因为他本身就是卖工艺品的，所以在内部他们会说我们写代码就要做到极致，代码就是我们的艺术品。你用任何方式，首先要把代码做好。在代码实现的过程中，你上线，一定会遇到问题。遇到问题没关系，最重要的是遇到问题不指责。我们只关注问题本身，而不是去纠出来是谁造成的。我们在思考的是说未来如何去改进它。\n所以在Etsy里面有一个特别著名的三只袖子的毛衣，相信大家可能都听过。三只袖子的毛衣，大家觉得不可思议，你织毛衣怎么能织出三只袖子来呢？他就是用这种隐喻来表达你造成了一个最意外的事物。最意外事物不是按照造成的后果，而是过程！越是没想到的东西，当然可能危害也很大，但是对大家的学习是最有用的，所以他们会内部非常崇尚这种精神。\n我们再来看facebook\nfacebook其中最强调的一点就是像黑客那样思考。我们知道黑客的行动能力是非常强的，所以在facebook里面强调快速行动，扎克伯格就说，如果你没有犯错，那就说明你不够快。因为现在的商业模式就是快，唯快不破。\n如何在快的过程中，又避免损失最小，这是非常重要的话题。所以在facebook内部最强调的是什么？大量的实验。所以他现在讲说facebook可能不是一个版本，而是一万个版本在同时的运行。所有的idea都是假设，假设的东西都是不靠谱的，我们都需要去快速的验证。\n另外一个不要太追求完美，因为现在我们太多的情况就是说我还没准备好，所以我要拼命的优化，但你优化的东西有价值吗？真不一定，用户都不care。所以这里面有一个尴尬理论，就是说如果你推出的第一版产品，无法让你觉得不好意思，那你说明你做多了。\n允许失败，不用多讲了，所以在facebook里面，曾经有一个实习生搞瘫了整个facebook30分钟，这在公司，就是大事，我们要找个背锅炉侠，这个实习生没有背锅，反而非常有名在facebook。还专门建了一个测试就与这个人名字相关，就叫“Ben测试”。总体来讲就是说你去尝试一些失败的东西，很好没问题，跟Etsy一样的事后不指责，我们其实是帮助所有人真正地去实现学习和技能的提升。所以在facebook经常会搞黑客马拉松。前两天“10·24”你会看到国内很多公司也在搞这个黑客马拉松。黑客马拉松就是要在短时间内各种角色拼命配合，快速的产生案例，快速去上线，快速去验证的一个短时间的爆发。\n接下来我们再来看几个小的案例，这个是跟国内的公司有关\n京东一直在提倡的也是叫客户为先和创新的东西。这个是跟亚马逊是有直接对标关系。京东的核心价值观其中有一条就是将客户为先，另外一条是创新。\n如何实现创新呢？其实在内部也会经常举办各种马拉松。在京东来讲参加马拉松就是一种福利，很多优秀的项目就是这么筛选出来的，因为好的idea平时可能没有施展的空间，那么我们提供一个平台，把你的idea贡献出来。然后你再去找一群跟你志同道合的一帮人，然后在24小时或者48小时之内把它做出来，让别人看到一个方向、一个原型就够了。\n我们也会举办代码赌场，我们也特别崇尚Code review，很多公司的Code review可能做得不好，没时间坚持下去，那怎么办？我们赌一赌。你代码写得好，我代码写得好，那我们就PK一下，谁赢了，谁把对方的钱赢过去，真刀真枪的，真掏钱的一个玩法。我们还有很多创新项目，带着大家一块去做快速的验证。\n其实除了我刚才提到的京东之外，国内也有很多公司，像美团他也强调了一些这种责任担当，共享，一种文化，这个我们就不多讲了。回头大家可以去搜一搜，也有相应的文章。\n现在特别火的字节跳动，字节跳动内部整个被称之为一个大的APP工厂。\n他们的内部做任何一个东西，简直就是快速的一个复制的能力。他通过这种能力来支撑整个业务的快速发展。其实它这种能力其实跟DevOps是息息相关的。回头大家也可以去再研究一下字节，字节里面我们稍微列了几个关键点。背后提倡的也是责任担当与信任。\n我今天快速给大家分享了很多案例，其实来讲，你要找这些案例，在个国内也好、国外也好都非常多，讲也讲不完。\n最重要的就是我们去先把你这个文化基础打好。文化需要的是信任、尊重与担当。让我们行动起来，有意识地去改进，其实DevOps这件事情也不是那么难。\n谢谢大家！我今天的分享就到这儿，也非常感谢各位来到我们中国的DevOps社区，希望大家一起来加入这个社区，为整个社区添砖加瓦，一起来推动中国DevOps的落地。\n关于作者 ![](/images/blog/devops-culture-056.png\u0026rdquo; /\u0026gt;\n王立杰（无敌哥）\n资深敏捷创新专家\n中国DevOps社区核心组织者\n华为云MVP，PMI-ACP认证讲师，规模化敏捷认证咨询师(SPC4)，多年产品研发管理与敏捷实施经验，专注于敏捷组织转型、研发效能提升、创新落地指导。 曾任京东首席敏捷创新教练，IBM 客户技术专家、百度高级敏捷教练、北大光华/新华都商学院MBA特邀讲师。\n","permalink":"https://devopschina.org/blog/building-a-culture-of-trust-respect-and-responsiblity-in-devops/","tags":["DevOps","文化"],"title":"万字长文演讲实录丨打造信任、尊重与担当的DevOps文化"},{"categories":["翻译"],"contents":" 译者：付文新\n  审校：韦世滴\n  原文(作者：Carla Rudder)：https://enterprisersproject.com/article/2019/8/devops-role-digital-transformation\n 从模式识别到新财源的发现，DevOps 在数字化转型过程中总是重要的角色。事实上，专家们总是说必不可少。\n弹性伸缩的 DevOps 并不是功绩，因为当你的 Devops 之旅停滞不前时，那么数字化转型也就没什么希望了。专家们说这两者之间有着内在的联系。\nDevOps 通过转变企业的文化倾向，打破壁垒，为持续改变和快速实验铺平道路，从而帮助企业成功实现数字化转型。 Conflux 咨询主管、团队拓扑的合著者 Matthew Skelton 说：“所有这些要素不但有助于企业满足不断变化的客户需求，而且有助于企业“自我引导”朝着更好的解决方案持续改进。\n如果不能在构建和运行 IT 系统中的不同团队之间进行良好的协作，数字化转型几乎不可能成功。现在的技术变革是如此之快，以至于不能期望一个单独的团队能够了解所有的技术细节，所以我们需要团队能够关注与一个较小的问题领域。如果没有基础设施自动化和精心挑选的团队，数字化转型的步伐将停滞不前。”\n哪一种方式能够帮助你所在的企业在数字化转型的目标上取得更大的成就？\nDevOps 有助于改变企业在文化上的思维倾向 来自 Harness 的 CI/CD \u0026amp; DevOps 传道者 Steve Burton 说：“DevOps 应该被称为加速任何现代化企业转变的催化剂，不管你是叫它数字化转型、云原生还是鲍勃的甜甜圈。DevOps 主要是讲述一种商业理念并帮助企业尽快实现这一理念；它并不是一种技术或者流行语。\n企业文化是许多大型组织或企业无法转型的原因，他们太固守于他们这25年来如何开发、运输和运营软件的方式了。DevOps 是一种文化上的思维倾向的转变，归根结底它是想要创建一种没有繁文缛节和官僚主义的环境。”\n DevOps 的目的是要提出一个业务构想，并帮助业务尽快实现该构想。它与技术或流行语无关。\n DevOps 有助于团结人、流程和技术 来自 Perfecto 的 CI/CD \u0026amp; DevOps 传道者 Eran Kinsbruner 说: “DevOps 让组织更快的向客户发布新的价值，从而促使这些组织成熟并改变数字面貌。Devops 团结人、流程和技术：当这三者协调一致朝着同一个目标时候，就是更快的引入变革的时候。\nDevOps 通过聚焦于数字化变革需要做的事，避免人力和工具的内部浪费，这本身就释放的更多的资源，这些资源要么隐藏，要么浪费在更低优先级的事务上，这样团队就能处理最重要和最关键的特性。\n没有 DevOps，新技术不能在足够短的时间内更快的发布以跟上竞争响应市场事件和满足客户需求；没有 Devops，也无法保证发布的质量和发布流程的自动化，而软件的拓展革新也变得更加困难。”\nDevOps 有助于发现利于组织改善的模式 来自 Ranger4 的 Devops 专家 Helen Beal 说：“DevOps 在数字化转型中的作用是帮助组织了解模式与实践，从而提高在面对数据混乱情况下的性能进而改善竞争态势。 从分级指挥控制的传统企业转变成权力分散、自治和平衡的数字化公司，需要所有人的付出，并做出重大的行为上的转变。\nDevOps 方法有助于我们理解为什么优化从理念到价值实现的流程不仅仅只是构建一个 pipeline，更重要的是从文化角度为我们提供了框架和模型。”\nDevOps 有助于团队自我引导 来自 Conflux 的咨询主管 Matthew Skelton 说: “DevOps 使得 IT 基础设施更易于测试，更具弹性，更易于观察，动态且按需配置。这使得数字转型能够更安全、快速的更改处于支撑地位的IT基础设施，从而实现对软件和服务更安全、快速的更改。我们还可以更快的发现操作需求，提高可操作性。DevOps 在数字转型中的作用还在与确保所有构建、部署和基础设施的更改都是版本控制的，不仅消除了手动配置的模糊性，而且还可以追溯历史版本。\n当与现在丰富的监测且可观测的数字遥测工具相结合的时候，我们最终对于我们的系统有了更为全面的认知，这有助于降低平均恢复时间（MTTR），使得团队真正能够拥有生产服务。这样反过来又有助于企业对不断变化的市场环境作出更快的反馈，从而自我引导出更好的解决方案。”\n DevOps 可以帮助使 IT 基础架构更具可测试性，弹性，可观察性，动态性和按需。\n DevOps 将自动化作为优先事项 来自 DevOps 培训机构的 CEO，Jayne Groll 说：“DevOps 制造了一个企业可以用来指定数字化转型战略的聚焦点。DevOps 增加流量、缩短反馈回路、鼓励持续学习和实验的原则是实现数字化转型的种子。IT 一直忙于自动化这个世界，我们几乎忘记了自动化自己劳动的优势。DevOps 提倡自动化并使之焕发新生。\n需要注意的是自动化本身并不是 DevOps 和数字化转型的神药。自动化必须由人编写，并由过程和文化支撑。没有 CI/CD/SRE 的自动化，数字化改造更加困难而且竞争优势也有限。”\n IT 部门一直忙于自动化世界，我们几乎忘记了自动化自己的工作所带来的好处。\n DevOps 打破壁垒 来自 InterSystems 的产品总监 Jeff Fried 说：“开发团队往往是数字化改造方案背后的策划者，他们构建并支持在企业范围内实现数字化改造的体系结构，无论是开发远程协作的应用程序还是维护基础设施以确保成功的数据存储和共享。任何成功数字转型的推出都伴随着创新步伐的加快，以及对按需更新和开发新工具的要求。因此开发必须适应 Devops 心态，这有助于团队成员加速测试和排除故障、跨组织合作、拥抱实验，最终推动创新，从而为他们的数字转型计划提供动力。\nDevops 增强数字化转型的一种强有力方式是打破壁垒。成功的数字化转型主动要求整个组织采取行动，但更常见的是传统商业做法，例如年度周期计划或者缓慢的流程体系。通过打破壁垒，开发团队可以更好的洞察整个组织中的哪些工作可行，哪些工作不可行，从而能够更快地改进并创建一种包含数字化转型带来的变化的文化。”\n DevOps 推动数字化转型的最大方法之一是打破组织孤岛。\n DevOps 提炼新的财源 BMC 的数字业务自动化总裁 Gur Steif 说：“在速度是市场生存需求的大气候中，Devops 是技术战略必须考虑的一部分。Devops 极大的提高了企业的灵活性，使之能对不断变化的需求和市场条件做出快速响应。\n无论你如何定义数字化转型，数字是基础，这就意味着转型依赖于新的或者更有效的方式利用技术来实现业务目标。DevOps 代表一种在整个价值链上的演进方式，使组织为市场带来新的服务，并提升效率，甚至新的财务来源，这在以前是根本无法想象的。”\n DevOps 极大地提高了敏捷性，可以对不断变化的需求或市场状况做出极快的响应。\n DevOps 赋能持续可靠的修改 Liberty Mutual 安全 DevOps 平台的高级架构师 Dave Ehringer 说：“我们看到的数字化转型大多是由多因素驱动的，比如希望业务能够更快的学习、迭代和运转。他们希望拥抱云技术，并通过微服务等方法来实现架构的现代化，希望扩大用户群体，实现更大规模的增长。但是如果没有响应的过程、文化和流程允许不断可靠的引入变革，这些目标根本不可能实现，而这恰恰是 DevOps 之所长。云计算和操作微服务技术引入了更多的复杂性。如果你在开发和运营上没有很强的一致性，那么成功的希望渺茫。DevOps 的规则和文化是绝大多数组织成功进行转变的燃料。”\nDevOps 使客户更快乐 来自 Accenture 的全球 DevOps 实践主管 Mirco Hering,说：“当系统发展缓慢系统本身是大型应用的时候，大规模的人力和分散的交付团队优化了成本，但在新的数字世界中，速度和反应能力比控制更重要。 DevOps 从技术和组织两个角度赋能，使之能处理速度和复杂性日益增长的需求。\nDevops 从三个方面赋能数字化转型，第一，它使得系统交付更可靠、更廉价也更快。第二、它提高了利益相关者的整体服务质量。先进的监控和补救方法意味着问题往往出现在客户发现之前，或者系统回退只会轻微的影响客户。第三、它有助于组织更好的系统，这可能是影响最深远的一点。\nDevOps 的组织结构是为了提高产品团队对新信息的反馈速度。这些信息可以通过允许进行功能性实验测评的遥测系统直接从生产环境直接获取。交付速度的提升和解耦的数字架构设计，使我们可以同时运行许多实验，创建使客户越来越快乐的系统。”\n 在新的数字世界中，速度和反应性比控制更重要。\n DevOps 支撑快速实验 来自 North Highland 的 Ben Grinnell,说：“数字化转型的一个重要方向是变成一个拥有相对竞争优势的公司，通过对市场上的客户进行实验并从中学习进而比竞争对手更快的修改与之交互的服务. 随着客户互动和学习不断赋能数字化，竞争优势的关键促成因素变成了以下这些：\n 能够对数字交互进行快速理解和诠释反馈的能力。 能够基于反馈以改进产品和服务的设计变更能力。 能够可靠地实现这些想法并将其投入市场以开始重新学习的速度。  DevOps 从本质上赋能以上三个方面，使数字化转型成为可能。这些经常出现在大公司的小部门，因此转型成功与否取决于规模化推广的能力。”\n","permalink":"https://devopschina.org/blog/devops-role-digital-transformation/","tags":["DevOps","数字化转型"],"title":"DevOps 帮助数字化转型的10个最佳实践"},{"categories":["翻译"],"contents":" 译者：王国良\n审校：Frank Li, 韦世滴\n作者：Iren Korkishko\n(原文)：https://medium.com/swlh/ui-ux-design-guide-with-terms-explanations-tips-and-trends-754b9356d914\n 这篇长文旨在汇集与创建网页和移动应用设计有关的 UX 和 UI 设计流程的所有理论。\n最初，我在 Syndicode 博客上分享了这篇描述我们在客户服务中所用的 UI 和 UX 设计流程的指南。由于这篇材料看起来非常有用和有指导意义，我决定在这里再次分享。\n大家知道，设计决定了大多数软件产品的成功。而软件开发拓展了把设计用于不同产品的新方式。我谈论的是关于网页和应用的设计。没有时尚元素和易用性，就没有伟大的应用程序。功能和吸引力的最优组合可以用来衡量应用的有效性。视觉传达必须简单、直观和吸引人。\nUI/UX 设计的作用 应用和网页设计面临着特殊的挑战：\n 指引复杂的任务和工作流程； 让用户能够理解和管理复杂数据； 容纳用户角色、需要和流程的各种变化。  但承担这种挑战是值得的。因为应用的有效设计和实现会在从娱乐到健康保健的广泛环境中对生产力、效率、准确性和满意度产生深远的积极影响。\n你之前可能听说过 UI 或 UX，但还没有实际机会了解它是用来做什么的、在什么场景下用，以及为什么要用。并且，UI 和 UX 不是一回事。在进一步之前，了解下 UI 和 UX 的基本不同之处。UX 是用户对产品的总体体验，而 UI 是用户具体与之互动和可以看见的东西。\n优秀设计的价值 成功的应用设计的关键并非是一个好的主意或好的功能，而是可以归结到用户体验（UX）和用户界面（UI）。如果 App 看起来很糟糕并且不太容易用，你的主意再好也白搭。\n要开发网页或移动应用的话，你务必要注意的一件重要事项是应用的外观与感觉。例如，如果你所从事的领域是电子商务，那么设计糟糕的应用程序会使你失去很多潜在客户。\n例如，用户打开你的应用后首先看到的是什么？用户首先看到的是登录页面。登录页面是什么呢？它是用户了解该应用或网页能否满足其需求和实现其需要的起始之点。登录页面必须富有吸引力，并且包含一些引导行动的按钮，以便用户知道下一步做什么。\n为了对 UI 和 UX 设计师的工作提供价值，以下给出了 UI 和 UX 的一些有趣对照：\n  UX 设计师就像建筑师。该角色关注用户，并且帮助你的业务提升可度量的指标（降低跳出率，提高点击率等）。UX 设计师理解用户行为和心理，了解界面人体工程学，并且能分析业务需要，将之转换为用户流程。\n  UI 设计师好比是一位装饰者。该角色关注界面能否反映出品牌。这部分更多是不可度量的东西（例如界面的舒适性，是否足够时尚等等。）UI 设计师了解颜色和颜色组合，了解如何阅读品牌说明书并将之转换为 UI 元素。\n  有时 UI 和 UX 设计师是同一个人，他负责整个设计流程。但我们分开讨论下每种类型的设计。\n什么是 UX 设计？ 用户体验设计是创建产品、系统或服务的流程，目的是向用户提供有意义和相关的体验。它涉及到获取和集成产品的整体流程设计，包括品牌、设计、易用性和功能方面。它也包含人机互动和拥有产品的有意义和有价值的方面。 UX 处理内容和网站地图的体系结构。\n提前说一下，我想说我们在下一部分将会谈到的 UI (用户界面)设计是 UX 设计的一个重要方面，或者说子集。UX 设计涵盖了大量其他领域。信息架构（IA）是 UX 设计的第二个重要方面。\nUX 设计帮助用户实现目标。它不只是专注于创建有用的产品，还涵盖用户体验的其他方面，例如：\n 愉悦 效率 情绪 娱乐  到目前为止，好的用户体验就是在目标用户使用产品的特定上下文中满足特定用户的需要。UX 设计以用户为中心 \u0026mdash;\u0026mdash; 用户的类型决定了设计的类型。\n那就是为什么 UX 设计是动态的，并且经常会由于使用环境的变化、个别系统的变化和使用上下文的变化等而随时修改。我也会介绍一些在2019年可以预期到的一些 UX 设计趋势。我们也可以说用户体验是关于用户与产品的互动和体验。\nUX 设计的主要任务是创建可裁剪的产品，以满足用户的特地需要，但提供的功能是可预期的。换句话说，UX 设计要学习用户的行为，理解用户的动机，目的是设计出更好的数字化体验。\n我们讨论一下 UX 设计的主要要求。完美的用户体验设计是什么？这个问题的答案可以用一个 UX 设计要求的列表来回答，这些要求要在不同层次上被满足。这些层次构成了 UX 设计金字塔。\nUX 原理与 UX 堆栈 UX 设计金字塔在每一层上的目标是通过以下主要的 UX 设计原则达到的：\n 层级结构  层级结构是设计师帮助用户在产品中轻松浏览的最佳工具之一。它包含：(a) 信息架构（内容在整个 App 或网站中是如何组织的）和 (b) 视觉层级（帮助用户在一个部分或页面中更加轻松地浏览）。\n一致性  在大多数情况下，可以通过使用一套关于如何为特定设备或格式设计产品的正式的指南来达到一致性。\n确认  对于任何重要或不可逆转的操作，通过要求确认来防止用户意外犯错。\n用户控制  “撤销”、“返回”、“搜索”这些按钮，以及键盘快捷键是在网站或应用中提供给用户控制的好方法。\n便利性  让尽可能多的人容易使用对一个产品来说是至关重要的。UX 设计应当为人们使用产品时消除障碍，不管这些障碍是临时的还是永久的。\nUX 设计需要平衡考虑业务、人和技术。然而很明显，没有健康的业务就不会有产品的成功，没有满意的客户就不会有成功的业务，而 UX 设计师的工作就是让客户满意。\n完整的 UX 设计栈 UX 设计牵涉到很多东西。完整的 UX 设计栈包括：\n 表现层（UI设计发挥作用的地方） 框架层（采用界面与互动设计） 结构层（采用信息架构） 范围层（关于功能规范） 策略层（根据用户调查和业务目标定义用户需要）  但我们不会先讨论 UI 部分。UX 设计开始于通过用户调查识别问题。解决用户不关心的问题毫无意义。\nUX设计流程 简而言之，UX 设计流程如下：\n 用户调查 设计   UX 线框图 UX 原型 UI 设计（视觉与交互）  用户测试  下面你会看到主要 UX 设计流程方法的概览。\n可以通过几个最流行的 UX 设计方法来描述 UX 设计流程。\nUX 设计流程的主要方法 目前，有三个广为人知的 UX 设计流程方法。\n 经典方法 精益方法 谷歌风投设计冲刺  经典 UX 设计流程通常在大学里教授，并且采用瀑布方法实施。经典 UX 设计流程如下：\n 调查。要发现出主要问题。有效的用户调查有10种图表。 对识别的问题进行分类。 创建角色和旅程地图（不要与用户流程混淆）。 通过构思练习为优秀的UX设计和解决用户问题产生解决方案。 创建原型。 原型测试。 向开发团队发送最终原型。 产品发布。 收集用户反馈。 根据收到的用户反馈，回到第一步。  简单来说，经典 UX 设计流程可以归纳如下：\n但是由于经典 UX 设计流程与敏捷开发不兼容，在2013年出现了 UX 设计流程的其他方法。新的设计流程被称为精益 UX，并且允许UX在敏捷的不确定性范围内操作，并能基于用户反馈快速更新设计。它使体验设计和产品开发和谐相处。\n简而言之，精益 UX 是一组基于精益创业敏捷方法的原则，其核心是关注当下。不像在瀑布模式中那样把设计交付物抛给下一个环节，而是团队认可最终设计无法事先创建，并相信答案会随着 MVP（最小可推行产品）假设测试的进行而涌现出来。精益 UX 流程可被描述为“构建、测量、学习”循环或“思考、制造、检查”循环。\n后来，当产品计划没有明确定义时，精益用户体验设计过程似乎效率低下，导致大量浪费和返工。\n谷歌风投建议了另一个伟大的设计流程。那就是设计冲刺。它允许团队快速定义和测试低保真原型。谷歌风投的设计冲刺可以看作是三种方法的结合：设计思维，敏捷和精益。 冲刺的一个关键组件是创建原型，这是收集数据和测试想法的最佳方法之一。这种方法可以通过以下方式呈现：\n所有的 UX 设计流程方法都是基于类似的迭代循环但是回答不同的问题。通过下面的文章，了解所有方法的不同之处和相同之处。\nUX设计的各个部分 作为小结，我将介绍UX设计的每个部分的更多信息：\n 交互设计（Interaction design）  通过对用户行为深思熟虑，创建出引人入胜的界面。在用户与界面之间产生简单和清晰的沟通。交互设计负责实现人与单个用户界面或多个相关界面（或系统）之间交互的功能。\n线框图与原型（Wireframes \u0026amp; prototypes）  在最终设计之前，用网站基本组件来演示任务的模型或交互原型。（顺便说下，线框图不是草图或样稿）。\n信息架构（Information Architect）  兼顾艺术和科学。以有效和可持续的方法对内容进行组织、结构化和标签。\n用户调查（User Research）  通过观察技术、任务分析和其他反馈方法，理解用户的行为、需要和动机。用户调查定义了受众，并提供了如何最好地满足他们需求的基本见解。为了提供定性的用户研究，我们应该考虑整体情况： \u0026mdash;\u0026mdash; 谁将使用应用程序/网站？ \u0026mdash;\u0026mdash; 他们想要完成什么？ \u0026mdash;\u0026mdash; 他们可能会遇到什么问题？ \u0026mdash;\u0026mdash; 主要客户的业务需求是什么？我发过一篇关于为什么用户研究对 UX 很重要的帖子。\n场景（Scenarios）  在项目中描述用户交互。他们的故事对于设计界面和可用性测试都非常重要。\n但这并不是 UX 设计所包含内容的完整列表。要找到用户体验设计的关键部分和真正的本质！\n用户体验设计决定了用户是翻页还是滚动内容。为了对这些细节负责并预测其所产生的影响，用户体验设计师应该对人类行为有充分了解。用户体验设计师通常来自各种背景，如视觉设计，编程，心理学和交互设计。稍后，我还将详细讨论UX设计人员的主要任务。\n什么是 UI 设计？ 让我们从接口的定义开始。接口是两个系统交互的机制。从这一点来说，用户界面是为促进系统和用户之间的直接交互而创建的界面。\n在显示设备上，有两种常见类型的用户界面：\n 命令行界面（CLI），仅包含文本，主要由程序员使用; 以及我将应用的图形用户界面（GUI）。它包括图像，窗口，图标，菜单等。  在本文中，我将特别关注负责视觉感知的用户界面类型 \u0026mdash;\u0026mdash; GUI。\nUI 或用户界面设计是为机器和软件（例如计算机，家用电器，移动设备和其他电子设备）设计用户界面的学科，其重点在于响应性和美观性，最大化可用性以促进良好的用户体验。作为 UX 的一部分，UI设计更侧重于颜色和排版。简而言之，UI设计通常是以下组合：\n 视觉设计（外观和感觉）； 交互设计（它是如何工作的）。  例如，用户体验设计侧重于将按钮放在哪里以便用户轻松找到它，而UI设计将考虑如何使这个按钮看起来漂亮，以使用户想要按下它。\n为什么我们需要用户界面？因为产品必须具有视觉吸引力和美观。 UI设计采用通用的视觉语言和层次结构，增强了用户与你的产品互动的方式。\nUI 汇集了交互设计，视觉设计和信息架构中的概念。\n用户界面元素包括按钮，文本字段，复选框，滑块，图标，标签，消息框，分页等。为了更好地理解 UI 设计是什么，你应该对主要的 UI 设计元素稍微学习一下。\nUI 设计的各部分 如果不使用以下所有技术，就无法开发出吸引人的用户界面设计：\n 视觉设计  采用制作一般产品的美学原则，按以用户为中心的原则与用户交互，并以此进行面向网络的设计或概念艺术。视觉设计的主要目标是借助插图，摄影，排版，空间，布局和颜色来塑造和改善用户体验。 \u0026lsquo;线条，形状，负空间，纹理\u0026rsquo; \u0026mdash;\u0026mdash; 它们都是关于视觉设计。在 Interactive Design Foundation 页面上了解有关视觉设计的更多信息。\n 颜色  为你的项目选择正确的颜色非常重要，因为它与情感和意义有着精神上的联系。遵循品牌颜色并根据你要创建的设计和要分享的信息明智地使用它们也很重要。\n 平面设计  平面设计负责将图像，排版或动态图形组合在一起，以给你的客户留下深刻印象。平面设计旨在追求像素完美。这是为了确保文本具有完美的字距调整，并且颜色符合品牌指南。平面设计是一门专业学科，需要具有一定的工艺水平和一系列专业技能（如排版和色彩理论），才能产生出色的视觉效果。它经常与视觉设计（Visual Design）混合在一起。\n 模型  比例或全尺寸模型用于演示，设计评估，促销和其他目的。模型意味着用视觉细节展示设计的最终外观，例如颜色和排版。线框，模型和原型通常是混合的，但它们只代表设计流程的不同阶段。线框是一种呈现设计的低保真方式，它概述了结构和布局。与线框不同，模型看起来更像是成品或原型，但它不是交互式的，也不是可点击的。模型提供了在应用程序中布局屏幕的各种选项。除了布局，它们还有助于组织内容并使用户界面易于理解。\n 排版  排版在各种形式的传播艺术中都是驱动力。它是关于字体样式，外观和结构的艺术和科学，旨在为读者提供一个美观和易读的副本。排版有助于在基于打印或基于屏幕的项目上为你的消息增加展示能力。好的排版应该：\na）在各种尺寸下工作良好;\nb）容易区分字体;\nc）具有可识别的层次结构以获得更好的感知。\n此外，现在UI设计在很大程度上依赖动作设计，这会产生对任何用户界面至关重要的即时用户反馈。动画，视觉效果和屏幕转换对初次使用者与应用的互动方式产生了巨大影响。在我的博客文章中查找关于动作设计的力量。\nUI 软件原型类型 正如我之前提到的，原型与线框和模型不同。我以前在 UX 设计中添加了原型，但是就用户通常用于测试产品而言，原型必须是高保真，交互式的，并尽可能地适应最终的用户界面。这就是为什么在下一部分我将谈论用户界面原型。\n原型尽可能逼真地模拟用户和界面之间的交互。\n有5种常见类型的 UI 软件原型：\n 纸张原型制作（草图绘制）  在原型制作过程中绘制草图以记录主要想法（通常在纸上），它仅限于创意生成和与设计团队的沟通。\n低保真原型设计  低保真原型是概念的粗略表示，有助于在设计过程的早期验证这些概念。简而言之，这是我们想法的原始表现。设计团队通常使用低保真原型来强调交互和思想。\n快速原型制作  快速原型制作是一种基于用户研究的中等保真技术。快速原型设计有助于设计人员思考需要采取哪些措施来实现最终目标。它经历了一系列可能解决问题的快速迭代和反馈会话。快速原型制作之所以快是因为使用了各种应用程序，不同的数字原型设计和用户研究工具。\n高保真原型设计（交互式原型设计）  与低保真原型设计不同，高保真原型设计需要更多时间，专业技能和资源。高保真原型是基于计算机的交互式设计，在细节和功能方面与最终版本最相似。它通常将可用性和现实性结合在一起。\nHTML 原型（有些人不算这种类型）  HTML 原型是使用 HTML 开发的原型。它可以在浏览器中看到。它没有风格选择，外观极小，但 HTML 原型可以比其他原型更快地进入编码阶段，因为它已经部分用代码编写。\n每种类型的原型都有自己的最适合这个过程的数字工具列表。从 Keynote 和 Google 幻灯片到 InVision 和 Adobe XD \u0026hellip;\u0026hellip; 你可以探索用于不同类型的UI软件原型设计的 UI 原型工具的最终列表。\nUI 设计原则 在创建 UI 原型时，优秀的设计师遵循接下来的6个用户界面设计原则（根据 Larry LeRoy Constantine 的观点）：\n  结构。它关注整体用户界面架构，并要求模型应该清晰，一致，可识别并包含相关的东西，分离不相关的东西，并使类似的东西彼此组合。\n  简单。设计应该使简单、通用的任务变得方便，用用户自己的语言清晰简单地进行通信。快捷方式必须与较长的程序有意义地关联。\n  可视化。没有多余的信息和奇怪的选择。设计应该为特定任务提供所有必需的选项和材料，而不会分散注意力。\n  反馈。应以清晰，简洁和熟悉的方式告知用户并使用户了解所有相关操作，状态或条件的变化，错误或异常。\n  容错性。设计应该灵活，通过允许撤消和重做来减少错误和误用。\n  重用。设计应重用内部和外部组件和行为，保持与目的的一致性，而不仅仅是强制一致性。\n  UI 技术 我们来谈谈如何满足上面提到的所有主要 UI 设计原则。为此，设计人员使用一些简单而有益的 UI 技术。\n首先，用户界面技术（交互技术或输入技术）是硬件和软件元素的组合，为用户提供完成单个任务的方法。例如，单击按钮，按键，执行鼠标手势或发出语音命令。\n在 UI 设计中，有数十种不同的有效技术可帮助用户完成任务。我想介绍最着名的 UI 技术。\n  交互式样式，如表单填写或菜单选择等。\n  交互设计模式，表示在特定上下文中描述常见可用性或可访问性问题的解决方案的方法。换句话说，这是记录常见设计问题的解决方案的正式方式。\n  组织结构和方案：\n  分层结构是基于大脑根据物理差异（如大小，颜色，对比度，对齐等）区分对象的能力。\n  用户遵循特殊路径逐个完成任务的顺序结构。\n  矩阵结构，即用户可以按字母顺序，时间顺序，主题（特定主题或类型的分组）顺序或用户组（一种类型的观众）自己选择导航方式。\n    内容组织模型：\n 单页模型。 平面模型，其中所有页面都处于相同地位，并且它们被放置在相同的导航级别。 索引模型，允许用户通过每页上可用的页面列表访问页面。 严格的层次结构模型为用户提供了一种从主页面访问子页面的方法。 共存层次结构模型为用户提供了访问内容的各种方法，但引导他们通过特定路径，以便他们采取按预期的操作。 雏菊模型旨在每次完成任务时将用户引导回主页。    可视化技术，强调输出，旨在以方便的方式和清晰、视觉上吸引人的方式组织和构建数字和非数字数据。\n  研究与创新。一些例子：\n 交互层; 定制插图; 分屏; 大胆的排版; 无按钮UI; 动画; 充满活力和大胆的色彩; 照片内容。    还有更多示例，但大多数示例可以在上面的组中进行分类。\n在你了解所有重要的 UI 技术后，我必须警告你注意那些最烦人的技巧。请考虑它们，以使你的用户免于灭绝。\nUI 设计流程 我可以说出的用户界面设计包含几个阶段和过程。以下是一些最可行的方法：\n  功能需求收集。 此步骤包括汇总完成项目目标所需功能的列表以及用户的潜在需求。通常，此阶段在与客户的探索会话之后立即开始。\n  用户和任务分析。 这是研究潜在用户将如何执行设计必须支持的任务的研究。这个阶段与用户研究相关，我们将其作为 UX 设计过程的一部分。\n  信息架构（IA）。 该过程涵盖了系统的过程和信息流的开发。在此阶段，我们选择 UI 交互风格，设计模式和可视化技术。我之前描述的许多 UI 设计技术都是在信息架构阶段形成的。\n  原型。 这个阶段包括原型，线框，模型，纸原型或简单交互式屏幕的开发。\n  可用性检查。 可用性检查可用于评估系统的原型或规格，通常无法在用户上进行测试。可用性检查方法是认知演练，启发式评估和多元演练。\n  可用性测试。\nUI 设计测试允许从观看者的角度理解对设计的接受情况。通常，在可用性测试期间，要求用户完成任务以查看他们在哪里遇到问题和困惑。\n  GUI（图形用户界面）设计。 这是最终图形用户界面设计的实际外观。在这个阶段，我们通过使用排版，摄影和插图来判断视觉交流和问题解决的情况。\n  软件维护。 部署后偶尔进行维护以修复软件错误，更改功能或完全升级系统。\n  在遵循 UI 设计过程的同时，不要忘记创建出色的用户界面设计的基本规则！\n在前面的部分中，我尝试收集，构建，解释并向你展示 UI 和 UX 设计的所有主要术语和细微差别。但你可能想要阅读更多有关它的内容，在这里你可以找到有关 UI 和 UX 设计的最佳书籍列表。\nWeb 和移动应用程序设计 UX 和 UI 设计主要用于为移动应用程序创建出色的网站和设计。让我们简要介绍一下网络和移动设计。\n网页设计 简而言之，网页设计是一个创建网站的过程。它涉及信息架构，网站结构，用户界面，导航人体工程学，网站布局，颜色，对比，字体和摄影或插图以及图标设计。\nWeb 设计师是将 UX 和 UI 技能应用于网页设计的专家。最初，网页设计师是 UI 设计者（UI 设计者的一个子集），专注于设计和构建 Web 用户界面。他们中的一些人可能知道一些前端编程，如 HTML / CSS，Javascript，以显示设计/原型如何在屏幕上工作。此外，他们应该更多地了解网络，网格等方面的技术限制。\n网页设计师应该：\n  知道如何创建 Web 布局和可交付成果，以及：\n 图标; 信息图表; 标志; 演讲等    熟悉行业标准软件。\n  有线框技巧。\n  注意前端发展的细微差别。\n  知道如何编码（这是一个加分项）。\n  用户体验的 UX 设计通过提高用户与网站交互的可用性，可访问性和效率来增强用户满意度。\n移动应用设计 移动应用程序设计（台式机和笔记本电脑）也面临着特殊的挑战：\n 指引复杂的任务和工作流程， 使用户能够理解和管理复杂数据， 适应各种各样的用户角色，需求和流程。  应用程序的 UX/UI 设计改善了用户体验和客户满意度，最终有助于增加特定应用程序的用户数量。\n移动用户体验设计是指在使用移动设备和可穿戴设备期间积极体验的设计。根据具体情况，移动应用程序设计对用户体验提出了独特的要求。\n了解移动用户体验设计的已被证明有效的8个关键原则。\n近年来，通过遵循下一代移动应用设计趋势，这些要求被满足了：\n 设计更大的屏幕; 简化用户界面; 通过滑动和手势进行交互; 添加更多导航选项; 添加功能动画; 讲故事; 使用可扩展的排版; 使用调色板实验等等。  要了解这些趋势，我建议你阅读有关 Web 应用程序开发的材料中 Web 应用程序和网站之间的主要差异部分。\n另一件需要考虑的事情是我们有时会听到的移动界面设计神话。说实话，这些神话中的一些可能会在过去发生，但现在移动体验更进一步。\n在2019年，为了使你的应用程序（网络或移动设备）具有吸引力和成功，你的网络或移动设计必须足够灵活，以拥抱现今可用的新技术和黑客技术。因为进步使得昨天出现的一些事情成为我们日常生活中必不可少的一部分。你想知道哪些创新可以促进你的业务并节省资金吗？\nUI / UX设计师做了什么？ 从 UX 设计人员的基本知识入手，用户体验设计师会考虑使用他们所使用的产品的原因，内容和方式。\n 为什么要关心用户使用产品的动机，无论是与他们想要执行的任务有关的，还是与跟产品的所有权和使用相关的价值观和观点。 用户在使用产品和功能时，解决了他们的什么问题。 如何将功能设计与易于访问和美观的方式关联起来。  用户体验设计师从“为什么”开始，然后确定“是什么”，最后，决定“如何做”，以创建用户可以形成有意义体验的产品。在网络或移动应用程序设计中，设计人员必须确保产品的“实质”来自现有设备，并提供无缝，流畅的体验。\n在“是什么‘阶段，UX 设计师应回答一些基本问题，如：\n 用户是否需要你正在制作的产品？ 用户会为此产品付费吗？ 用户会花时间寻找它并学习使用它吗？ 用户需要的主要功能是什么？ 用户是否需要你构建的所有功能？他们真正需要多少功能？  ”如何做“阶段的主要问题有所不同，并与实现相关：\n 如何组织内容以便用户轻松找到它？ 该应用程序是否易于使用？ 用户是否可能会感到困惑或迷失？他们可能遇到什么困难？ 需要什么内容以及如何编写最具吸引力的内容？  用户体验设计师的典型任务各不相同，但通常包括用户研究，创建角色，设计线框和交互式原型以及测试设计。\n简而言之，UX 设计师参与进行广泛的用户研究，制定信息架构以及创建用户配置文件和故事。用户体验设计师不一定拥有视觉或图形设计技能，但是，理解心理学和系统设计是必须的。\nUI 设计师同时尝试将复杂结构分解为简单易懂的格式，以方便最终用户。因此，UX/UI 设计师和网页设计师一道工作，为用户创建有效的和美好的体验。\nUI/UX 设计师应当能够理解用户的需要。应用的目标依然是首要的决定因素，这远在他们施展才能创建网页应用、移动应用、网站和服务之前。在理解了用户的需要和应用的目标之后，设计师应当能有有效地将它们转换成功能描述。他们必须能够决定应用未来可能的需求。在与其他开发团队成员的长期合作中，设计师在从产品开发的开始阶段到最终完成，都要参与。这些任务和职责构成了用户体验设计师的主要工作。但我建议你阅读UX设计师职责的更多资料。\n在我工作的公司，我们简化了 UI/UX 设计流程。这取决于你同时并行的项目数量。另外，当从业人员的经验增长后，完成整个流程的时间也会缩短。技巧能帮助你工作得更快。\n我们是怎么开始的？我们与客户有一个探索会议以发现有关项目的尽可能多事项。这个会议的主要目的是收集关键项目信息使我们获得一个高层面的理解。接着我们根据在 UI，UX，网页，移动设计方案上的工作内容创建计划，并就每一步与客户达成一致。然后我们根据精益UX回顾UI和UX设计流程的每一个必要的步骤。\n","permalink":"https://devopschina.org/blog/ui-ux-design-guide-with-terms-explanations-tips-and-trends/","tags":["UI","UX"],"title":"UI/UX 设计指南：术语、说明、技巧与趋势"},{"categories":["翻译"],"contents":" 社区译者：陈文峰\n审校：韦世滴\n原作者:Aymen El Amri and Sahil Sharma\n(原文地址)：https://medium.com/faun/the-must-know-checklist-for-devops-site-reliability-engineers-update-8ba44dbc824\n 对于布道者来说，DevOps 是一种文化和转型。对于一些工程师来说，DevOps 是一套敏捷的工具和技术的集合。对于经理来说，DevOps 可能是一种方法论。对于其他人来说，这只是一个时髦术语；对于招聘者来说，DevOps 是一份职位。\n我认为 DevOps 不仅仅是一个流行语，但不知何故它变成了以上所有定义的混合：如果没有正确的方法论、合适的工具集和合适的工程师，就没办法完成数字化的转型。\n在上一篇文章中，我写了15点 DevOps 检查列表，描述了在业务中实施 DevOps 的方法。这篇文章更多关于 DevOps、SRE 工程师所需的技能。下面列出的许多要点都是针对 *nix 环境的，这并不意味着适合 Windows 爱好者的 DevOps 环境。\n这个清单并非详尽完整的，仅列举了基础的技术，必须知道的技能和一些即兴的想法。您可以将它们用作评估清单来评估您自己或其他人，或为您的下一次 DevOps/SRE 工作面试做准备。\n这个清单是个人人坚持推荐的清单。\n 首先，一定要了解文化要点的重要性，可以通过点击这里了解更多 DevOps 15项检查表。 您需要掌握 *nix 系统，并充分了解 Linux 任务调度的工作原理。 不用担心终端，您可能有 GUI 界面来管理您的服务器。但无论是什么情况，您都必须爱上终端，它更快、更安全、更诚实，一旦掌握它就非常容易使用。 如何获取 CPU 和系统信息（如 cat /proc/version、cat /proc/cpuinfo、uptime \u0026hellip;）。 Cron 任务如何运作。如何将 cron 任务设置在指定日期/时间/月。 如何知道您在计算机上运行的操作系统是什么版本（cat /etc/lsb-release） 了解不同的 *nix 操作系统之间的差异以及如何知道您在计算机上运行的操作系统是什么版本（例如cat /etc/lsb-release）。 几个 shell 命令之间的区别：sh，dash，bash，ash，zsh 。 如何设置和取消设置 ENV 变量。导出 ENV 变量是暂时的，如何导出永久变量？ 什么是 shell 配置文件：例如 ~/.bashrc，.bash_profile，.environment ，如何操作程序初始化文件的配置源码。 必需了解 Vim、它的配置（.vimrc）及其一些基本技巧。 日志如何在 *nix 系统中运行，什么是日志记录级别以及如何使用日志管理工具（rsyslog，logstash，fluentd，logwatch，awslogs \u0026hellip;）。 交换分区如何工作的。什么是交换性。（swapon -s，/proc/sys/vm/swappiness，sysctl vm.swappiness \u0026hellip;）。 如何在查看/设置网络配置。 如何在具有不同子网的计算机上设置静态/动态 IP 地址？ （提示：CIDR） 如何查看/设置/备份您的路由器设置？ DNS 如何工作？如何设置 DNS 服务器（Bind，Unbound，PowerDNS，Dnsmasq \u0026hellip;）？递归和权威 DNS 有什么区别？如何解决 DNS 故障（nslookup，dig \u0026hellip;）。 熟悉 DNS 和 A，AAAA，C，CNAME，TXT 记录。 SSH 如何工作，如何调试它以及如何生成 ssh 密钥以及无密码登录到其他计算机。 如何设置 Web 服务器（Apache，Nginx \u0026hellip;）。 Nginx 和 Apache 有什么区别？什么时候使用 Nginx？什么时候使用 Apache？您可以在同一个 Web 应用程序中使用它们，何时以及如何使用它们？ 如何设置反向代理（Nginx \u0026hellip;）。 如何设置缓存服务器（Squid，Nginx \u0026hellip;）。 如何设置负载均衡（HAproxy，Nginx \u0026hellip;）。 什么是 init 进程？你知道 Systemd（自 Ubuntu 15.04 开始使用），Upstart（由 Ubuntu 开发），SysV \u0026hellip; 熟悉 Systemd 以及如何使用 systemctl 和 journalctl 等命令分析和管理服务。 从源代码编译任何软件（gcc、make 和其他相关内容）。 如何通过终端压缩/解压缩不同格式的文件（主要是：tar/tar.gz）。 如何设置防火墙（使用 iptables 或至少为 ufw）：设置规则、列表规则、路由流量、阻塞协议/端口 \u0026hellip;。 了解最常用的默认运行服务端口号（如：SSH（22），Web（80），HTTPS（443）等）。 了解如何在生产环境中实时调试和跟踪运行的应用程序。 能轻松自如使用脚本语言。Bash 是必须掌握的（其他脚本语言也非常有用，如 Python，Perl \u0026hellip;）。 了解如何使用至少一个配置管理和远程执行工具（Ansible，Puppet，SaltStack，Chef 等）。您的选择应基于以下标准：语法、性能、模板语言、推送与拉取模型、架构、与其他工具的集成、可扩展性、可靠性等。 了解如何配置和使用持续集成和持续交付工具，如 Jenkins、Travis CI、Buildbot、GoCd。将这些工具与其他工具（如 Selenium、构建工具、配置管理软件、Docker、云提供商的 SDK 等）集成是非常价值的。 学习分布式版本控制系统 Git 及其基本命令（pull / push / commit / clone / branch / merge / logs 等）。了解 Git 工作流程。你知道如何将 Git 存储库恢复到上一个的提交吗？ 了解如何使用 SSH 密钥。尝试使用 Github、Bitbucket 或 Gitlab 等来配置对 repo / account 的无密码访问。 熟悉 Vagrant 等工具，使用它们创建可分发和可移植的开发环境。 开始研究基础设施即为代码和基础设施配置自动化工具（如 Terraform 和 Packer）。 开始研究容器和 Docker。它的底层机制（cgroups 和命名空间）怎么运行？ 开始熟悉基本的 Docker 命令（logs / inspect / top / ps / rm），另请查阅 docker hub（推/拉镜像）。 开始研究容器编排工具：Docker Swarm，Kubernetes，Mesosphere DC / OS，AWS ECS。 深入研究 DB（MySQL 或任何其他你喜欢的）。 学习 Redis / Memcache 和类似工具。 你的备份策略是什么？如何测试备份是否可靠。 你知道 ext4、ntfs、fat 吗？你知道 Union 文件系统吗？ 发展您的云计算技能。首先选择云基础架构提供商：Amazon Web Services、Google Cloud Platform、Digitalocean、Microsoft Azure。或者使用 OpenStack 创建自己的私有云。 那么模拟服务器呢？您的单元测试测试策略是什么？端到端？那你真的需要模拟服务器吗？谷歌“模拟服务器必将消失”。 阅读有关 PaaS / Iaas / Saas / CaaS / FaaS / DaaS 和无服务器架构的知识。 了解如何使用 Cloud Shell 从您的 CLI 或使用 Cloud SDK 的程序中使用和配置云资源。 您熟悉 OSI 模型和 TCP / IP 协议规范吗？ TCP 和 UDP 有什么差别？你知道 vxlan 吗？ 掌握实用的命令，如进程监控命令（ps，top，htop，atop \u0026hellip;），系统性能命令（nmon，iostat，sar，vmstat \u0026hellip;）和网络故障排除和分析（nmap，tcpdump，ping，traceroute，airmon，airodump \u0026hellip;）。 了解 HTTP 状态代码（2xx，3xx，4xx，5xx）。 你熟悉 IDE（Sublime Text，Atom，Eclipse 等）吗？ 网络数据包分析：tcpdump、Wireshark 等工具。 当你在浏览器中点击 google.com 时会发生什么？从浏览器的缓存，本地 DNS 缓存，本地网络配置（主机文件），路由，DNS，网络，Web 协议，缓存系统到 Web 服务器（如果深入讨论的话最基本的问题都是很难的）。 熟悉混乱的内核版本以及如何更新补丁。 熟悉 SSL / TLS 的工作原理以及数字证书的工作原理（https）。 熟悉安全协议：TLS，STARTTLS，SSL，HTTPS，SCP，SSH，SFTP，FTPS 等。 了解 PPTP，OpenVPN，L2TP / IPSec 之间的差异。 如何生成校验串（md5，SHA \u0026hellip;）来验证任何文件的完整性。 了解整体架构和微服务架构之间的区别。 了解微服务架构的优缺点，并开始构建类似的架构。 你知道什么是 ChatOps 吗？您是否尝试过使用其中一个已知框架？ Hubot，Lita，Cog？ 如何实现零停机部署？您制定回滚、自我修复、自动扩展的策略是什么？ 熟悉 API 和服务：RESTfull，类 RESTful，API 网关，Lambda 函数，无服务器计算，SOA，SOAP，JMS，CRUD。 学习有关无状态和有状态的应用程序。 阅读 DevOps 相关词汇表（Google it）。 如何守护您的基础架构，网络和运行的应用程序？ 了解如何设置、配置和使用某些监控系统（Nagios，Zabix，Sensu，Prometheus \u0026hellip;）。 阅读有关开源以及如何为开源项目做出贡献的信息，欲了解更多信息：http：//jvns.ca/blog/2016/10/26/a-few-questions-about-open-source/。 如果您的系统出现问题，您应该能够进行反思总结改进。使用文档详细记录出现问题的方法，以及我们如何防止再次发生错误。 尝试学习 StackOverflow 的专家如何解决任何问题。永远记住，这是不断变化的技术而不是基础不变的。基础知识总是保持不变。 让 Google，StackOverflow，Quora 等专业论坛成为您的朋友。 尝试建立良好的开发实践和可靠的架构。 了解如何在生产环境进行扩展。 关注开源项目（Kubernetes / Docker 等）或者让您感到兴奋的事情。 在邮件列表/公共论坛/技术聚会上提出问题/疑问/问题并从中学习。 关注来自社区的志同道合的人，并了解最新的技术趋势。 关注一些体面的科技公司工程博客（我们遵循：Google / Uber / Quora / Github / Netflix）。这是您可以直接从专家那里学习的地方，并有机会看到他们解决任何问题的方法。 浏览一些聚合资讯，如Reddit，黑客新闻，媒体等。 在 twitter 上关注志同道合的开发人员和技术公司。（我总是阅读文章和观看会议/会议，反思总结是我最喜欢的内容。我也会跟进着一些 Github repo 看看我使用的技术发生了什么。） 阅读各种与技术相关的博客并订阅 DevOps Newsletters。 如果可能的话，参加当地的聚会和会议。您将有机会从资深人仕和其他人那里学到很多东西。 了解可伸缩性和高度分布式系统。如何让它们始终保持运行状态？ 最后但并非最不重要，阅读书籍。  如果您拥有大部分技能，则可以确保您具备 DevOps，SRE 和系统工程师的能力条件。\n你无法一次性学习所有这些，但拥有正确的心态是重要的。即使熟悉所有这些也肯定需要时间。你可能会失败很多次，从你的错误中吸取教训，不要重蹈覆辙。\n永远记住，我们都是学习者。我们通过推敲和试验来学习。失败时不要气馁，因为这是我们学习的方式。\n我们很乐意听取您的建议，将其归类并添加到此列表中。\n","permalink":"https://devopschina.org/blog/the-must-know-checklist-for-devops-site-reliability-engineers-update/","tags":["DevOps","SRE"],"title":"DevOps和SRE工程师必需知道的检查清单"},{"categories":["翻译"],"contents":" 社区译者：朱婷\n  审校：韦世滴\n  原文地址(原作者:CloudSploit)：https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea\n 最近披露的一个因云安全配置错误导致个人敏感信息丢失事件成为上周的头条新闻。伴随着来自被告方的起诉书中更多信息的公开，我们整理了这一特殊事件公开的数据并对已发生的事情进行有根据猜测：此次事件导致超过1亿张信用卡申请数据资料以及十万个社会保险号丢失。\n这一直在发生 黑客事件的根源在于一个常见的问题：云基础架构资源的错误配置允许未经授权的用户提升其权限并破坏敏感信息文档。类似的事件在过去的2-3年里引发了新闻关注，其中包括引人注目的近2亿选民记录、五角大楼的数十亿份机密文件和5亿个 Facebook 个人资料事件。\n论据分析 据12页的起诉书 (PDF)内容，这种授权协议起因于 Capital One 的 AWS 账户可以在运行的服务器上任意调用用户请求。起诉书没有对触发这些命令的漏洞进行详细说明，但大多数迹象表明它是服务器端请求伪造（SSRF）漏洞攻击。SSRF 攻击诱使服务器代表远程用户执行命令，使用户将服务器视为其请求的代理，并获得对非公共终端的访问权。\nAWS 元数据服务 由于此服务器托管在 AWS 中，因此它可以访问元数据服务的唯一 URL:http://169.254.169.254。通常此 URL 用于提供 HTTP API，以获取节点级别信息，例如节点的 IP 地址、AWS 网络中的位置以及主机名。对于 AWS 云中的应用程序开发人员而言，这是一项非常有用的终端服务。\n元数据服务的一项特别重要的功能是提供临时凭证，该凭证可根据实例中IAM角色定义的权限策略为节点提供其他 AWS 服务的访问权限。IAM 角色可以替代长期使用的用户访问密钥和密文；应用程序定期向元数据终端请求凭证，而不是将访问密钥硬编码到应用程序的配置中。所有 AWS 开发工具包（SDK）都会通过一连串的检查来自动处理此请求。在这些检查中，它们会在环境变量、配置文件、本地应用程序代码或元数据终端中查找凭证的内存指示位。\n催化剂 将早期的 SSRF 攻击与 AWS EC2 服务器可以访问包含临时证书的元数据终端的知识结合起来，攻击者能够欺骗服务器向以下 URL 发出请求：http://169.254.169.254/iam/security-credentials。该终端返回了一个角色名称，该起诉状中列出了该角色名称为\u0026quot;*****-WAF-Role\u0026rdquo;，这表明所访问的服务器可能是 Capital One 网络上的 Web 应用程序防火墙。拥有角色名称后，攻击者便查询了整个终端： http://169.254.169.254/iam/security-credentials/*****-WAF-Role 它返回了最初分配给 EC2 实例本身的整套临时凭证：\n{ AccessKeyId: \u0026#34;\u0026lt;access key\u0026gt;\u0026#34;, SecretAccessKey: \u0026#34;\u0026lt;secret key\u0026gt;\u0026#34;, } 这些是标准的 AWS 凭证，可用于通过 AWS CLI 或任何 SDK 访问 AWS API。由于 IAM 角色没有附加禁止在 Capital One 外网使用的条件，因此地球上的任何人都可以使用这些凭证像 EC2 实例一样在内网将自己的 API 请求签名到 AWS API。\n累加效应 根据起诉书，一旦攻击者获得了对这些凭证的访问权，她便运行了 AWS S3 “ListBuckets” 命令。为此，IAM 角色策略允许通过其 IAM 策略中定义的权限来调用 API。该起诉书没有概述分配的确切权限，但是我们可以假定它至少允许了此类 API 调用（如果没有太多的话）。以下策略就足以引发此攻击，如下:\n{ \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Actions\u0026#34;: [ \u0026#34;s3:ListBuckets\u0026#34;, \u0026#34;s3:Sync\u0026#34; ], \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } 运行 s3：ListBuckets 之后，将会打印出包含受感染帐户中所有 AWS S3 存储桶的完整列表。\n$ aws s3 ls 2019-08-01 11:01:10 bucketone 2019-08-01 12:00:23 buckettwo 起诉书提到该命令被运行了几次，并使用 AWS s3：Sync 命令将这些存储桶中的数据复制到攻击者的本地计算机上，这引发了后面铺天盖地的媒体报道。\n$ aws s3 sync s3://bucketone . 什么地方出了错？ 这次攻击是系统漏洞与错误配置相结合的最终结果。SSRF 攻击获得了元数据终端访问权限是整个事故的关键，但是错误配置使安全漏洞演变为后续的全面沦陷。\n安全分层通常被称为安全洋葱。一旦攻击者获得对实例的IAM凭据的访问权限，她便利用严重的配置错误（该实例列出了过多的权限），访问了大量 S3 存储桶中的数据。\n虽然很容易将数据丢失归咎于 Capital One 的开发人员，但事实是，几乎每个 AWS 账户中都可能存在 IAM 角色配置错误。很少有开发人员花时间仔细列出所需的每个权限。通配符经常在不该应用的地方被更多的使用，从而导致被意外访问。如果没有攻击侵害因素，这种配置错误可能会被无期限地忽略。\n有人也可能会辩论说，事故是由于 Capital One 没有足够的监控来检测网络外部对凭证的初始访问导致。根据起诉书的分析，我们可以得出结论，CloudTrail 日志记录已启用。这些日志可以表明该角色当时正在从外部被访问使用，Capital One 可以有足够的时间供某人做出响应并停用该角色的权限。\n正确的做法 尽管这无疑是一个可怕的情况，但是 Capital One 能够找到有问题的确切请求这一事实，意味着它们至少遵循了启用 CloudTrail 日志的最佳实践。\n此外，虽然先前发生的许多事件是由 S3 存储桶权限可以直接被公共访问引起的，但在这个案例中似乎并非如此，而是攻击者能够通过外部漏洞获得内部访问。\n保护自己 如果我们不得不猜测，我们打赌大多数 AWS 账户都容易受到上述至少一半的攻击。创建紧耦合的 IAM 策略非常耗时，并且将来可能很难向应用程序中添加其他功能。\n至少考虑以下几点建议：\n  确保每个应用程序，EC2 实例或自动伸缩群组具有其自己的 IAM 角色。不要在不相关的应用程序之间共享角色。\n  调整每个角色的权限范围，仅允许访问所需的 AWS 资源。上述 “WAF” 角色不需要“在正常业务过程中”（根据起诉书内容）访问列表 S3 存储桶。\n  如果可能，在 IAM 角色中设定“条件”语句，以限制对已知 IP 地址或 VPC 终端的访问。\n  确保在所有区域和所有服务中都启用了 AWS CloudTrail。如果您在 S3 中存储了特别敏感的数据（社会安全号码肯定合格！），请确保 S3 存储桶对象可以启用读取日志级别权限。\n  监视 CloudTrail 日志中的可疑活动，如从已知网络地址之外的 IP 访问 API。\n  持续审核 Web 应用程序是否存在应用程序安全漏洞，请牢记基于云的应用程序可以集成到更广泛的 AWS 生态系统中，因此可以访问其他终端和服务。\n  结论 云安全是极富挑战性的。此事故正如我们在过去几年中看到的很多其他黑客那样，有时一家公司要丢失数百万条记录或客户数据，仅仅是因为在 IAM 策略中使用了星号。持续审核和监视这些问题对于维护安全的云环境至关重要。\n","permalink":"https://devopschina.org/blog/a-technical-analysis-of-the-capital-one-hack/","tags":["Analysis","Hack"],"title":"Capital One 事故的技术分析"},{"categories":["翻译"],"contents":" 社区译者：王英伟\n  审校：韦世滴\n  原文地址(原作者：Igor Kantor)：https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-366097df7737\n  注意： 这只是第一部分，另一部分在这里。\n 目标读者 你是一个想转型成为 DevOps 工程师的开发人员吗？\n你是一个受过正规培训的运维人员并且你想了解整个 DevOps 体系都包含什么内容吗？\n或者你都不是，你只是一名技术人员，你正在尝试职业转型，但是却不知道从哪里开始？\n如果是这样，请继续往下阅读，因为我们尝试将在六个月内指导你如何成为一名中级 DevOps 工程师！\n最后，如果你已经从事 DevOps 工作多年了，你可能仍然会发现这篇文章很有价值，因为它可以帮助你确定目前的现状和未来的发展方向。\n目前现状 首先，明确 DevOps 是什么？\n你可以在谷歌上搜索这些定义，浏览所有这些流行的词汇。但你会看到，大多数都是令人费解的冗长的描述语句。（看看我在这里会怎么做？）\n因此，我会帮你做以下总结：\n DevOps 是一种团队共同承担痛苦和责任的软件交付方法。\n 仅此而已。好吧，那具体含义是什么呢？\n按照传统思维模式，开发人员（开发软件的人）和运维人员（维护软件运行的人）的工作目标完全不同。\n例如，作为开发人员，我希望尽快、尽可能多的开发新功能。毕竟，这是我的工作，也是客户的要求！\n但是，作为运维人员，那么我想要尽可能少的交付新特性，因为每个新特性的交付都会伴伴随着风险。\n正式因为这种不一致的目标，导致 DevOps 诞生了。\nDevOps 试图融合开发和运维到一个团队。其理念是，一个团队现在将承担面向客户的软件开发过程中每个环节，并共同承担痛苦和责任（以及由此产生的回报）。\n现在，纯粹主义者会告诉你，没有所谓的 “DevOps 工程师”。“DevOps 是一种文化，而不是一个角色。” 这种说法在理论上是正确的（最糟糕的一种正确！）但是，正如它经常发生的那样，这个词已经超出了它原来的含义。\n现在，成为一名 DevOps 工程师就像是“系统工程师2.0”那样。换言之，了解软件开发生命周期并使用软件工程工具和过程，来解决经典问题的人。\n DevOps 最终意味着构建自动化流水线，从开发人员的笔记本电脑上获取代码从而产生最终收益！\n 同样要注意的是，作为一个职业选择，DevOps 有很完善的职业发展路径，几乎所有的公司要么“做 DevOps”，要么声称这样做。无论公司在哪里，DevOps 的整体就业机会都是丰富的，为未来几年提供了非常多的就业岗位。\n注意：对于为“DevOps 团队”或“DevOps 部门”招聘员工的公司需要小心。严格来说，这类事情不应该存在。因为最终，DevOps 都是提供关于软件工程的文化和方式，而不是新的团队或部门。\n放弃 现在，让我们把一杯苦艾酒放在一边，考虑一下下面的内容。你听过一句古老的格言吗：“没有初级的 DevOps 工程师？”\n如果没有听过这个格言，请知道它是 Reddit 和 StackOverflow 上的一个流行比喻。但这意味着什么？\n简而言之，这意味着需要多年的经验，再加上对工具的扎实理解，才能最终成为真正有效的高级 DevOps 实践者。可悲的是，没有捷径可寻。所以，这不是可以尝试欺骗的岗位——我认为这实际上不可能模拟成一个有几个月经验的高级开发人员工程师。对快速变化的工具和方法的深入了解需要数年的时间才能掌握，这一点是无法回避的。\n然而！对于大多数公司使用的工具和概念，有一个大致一致的流行的体系结构，这就是文章的全部内容。\n同样，工具不同于技能，所以当你学习这些工具时，要确保你不会忽视你的技能（面试、网络、书面交流、故障排除等）。\n最重要的是，不要忘记我们正在追求的目标——建立一个完全自动化的流水线，将想法转化为创收代码。这是这篇文章中最重要的一部分。\n我们从哪里开始？ 下面是你的知识学习路线图。\n掌握以下知识，你就可以称自己为 DevOps 工程师！如果你讨厌 “DevOps” 这个头衔，你可以自称为“云工程师”。\n下面的地图代表了我（以及在这个团队工作的大多数人）对一个称职的 DevOps 工程师应该掌握的知识体系的看法。也就是说，这只是一种参考，肯定会有反对的声音。没关系！我们在这里并不追求完美，我们正在尝试建立一个共享的基础知识技能图谱。\n注意：您应该首先一层一层地遍历学习这个知识体系。开始先打基础。首先学习蓝色的技术（Linux|Python|AWS），然后如果时间允许或就业市场需要，再学习紫色的技术（Golang|Google Cloud）。\n再次，在时间允许的情况下，在第二层（紫色部分知识技能）之后增加您的专业知识的深度。\n老实说，上面的基础层是你永远无法停止学习的。Linux 很复杂，需要多年才能掌握。 Python 需要不断的练习来保持最新状态。AWS 的发展如此之快，以至于你今天所知道的知识，在一年后仅仅是整个知识体系的一小部分。但是一旦你合理地掌握了基础层，就进入实际应用的技能集合。请注意，总共有6个蓝色列，每个月一个。\n注意：上面的流水线明显缺少的是测试环节。这是故意的——编写单元、集成和验收测试并不容易，而且传统上都是由开发人员承担的。这里是有意遗漏“测试”阶段的，因为该路线图的目标是快速吸收新的技能和工具。作者认为缺乏测试专业知识，对合适的 DevOps 职业发展路线来说是一个很小的障碍。\n另外，请记住，我们不是在学习一大堆不相关的技术。我们需要对工具有一个扎实的理解，然后工具结合在一起，完成一个单一、连贯的流水线任务。这个任务是端到端的自动化过程——一个以流水线的方式运行的数字化流程。而且，你不能学一堆工具就停下来。工具的变化很快，概念的变化要小得多。因此，您要做的是掌握这些工具背后的概念。\n基础知识 在标记为“基础”的顶部，您将看到每个 DevOps 工程师必须掌握的技能。\n在这里，您将看到三个主要的方面：操作系统、编程语言、公共云。这些东西不会是你能很快学会的东西，把它们从列表中勾选出来，然后持续学习。这些技能将是你必须不断学习和保持敏锐的技能，并随时关注最新进展。\n Linux  运行在各处的操作系统。现在，你能成为一个优秀的 DevOps 实践者，并完全留在微软生态系统中吗？当然可以！没有法律规定 Linux 必须为唯一的操作系统。但是请您了解，虽然所有的 DevOps 工作都可以通过 Windows 来完成，但这会更加痛苦，工作机会也会更少。所以，您完全可以假设，不了解 Linux 就不能成为真正的 DevOps 专业人员。因此，Linux 是您必须学习和不断学习的东西。\n老实说，最好的方法就是在家里安装 Linux（Fedora 或 Ubuntu），并尽可能多地使用它。你将破环操作系统，你将被卡住，然后你又不得不修复它，在这个过程中，你将学习 Linux！作为参考，在北美，红帽变种更为普遍。因此，从 Fedora 或 Centos 开始是有意义的。如果你想知道是应该使用 KDE 还是 Gnome 版本，那么就从 KDE 版本开始。这就是莱纳斯·托瓦尔兹所用的。\n Python  现在主要的后端语言。容易入门，使用广泛。另外：python 在人工智能/机器学习领域非常流行，所以如果你想转换到另一个热门领域，你就可以做好准备了！\n 亚马逊云服务  如果你要成为一个经验丰富的 DevOps 专业人士，必须对公共云的工作方式有扎实的了解。如果你想学习云相关的知识，那么亚马逊云服务就是这个领域的主导者，它提供了最丰富的工具。\n是否可以从 Google Cloud 或 Azure 开始？当然可以！但我们尽量学习市场占有率最高的产品，所以至少在2018年，AWS 是占有市场占有率最高的公有云产品。当你在 AWS 注册一个帐户时，你会得到一个免费使用空间，所以这是一个很好的开端。现在，当您登录到 AWS 控制台时，会看到一个简单易懂的选项菜单。\n这是个讽刺。好消息是你不需要了解亚马逊的每一项技术。从以下内容开始：VPC、EC2、IAM、S3、CloudWatch、ELB（在 EC2 的套件中）和安全组。这些东西足以让您开始工作，而且每一个现代支持公有云的企业，都将大量使用这些工具。\nAWS 自己的培训网站是一个很好的学习起点。我建议您每天留出20-30分钟来练习 Python、Linux 和 AWS。\n注意：这将是除了其他你必须学习的东西。总的来说，我估计每天花一个小时，一周五次，足以让你在6个月或更短的时间内对 DevOps 的知识体系有一个全面的了解。同样，共有6个主要支柱，每个支柱对应一个月的学习。这就是基础层！\n在后续的文章中，我们将探讨下一个题目：如何以完全自动化的方式配置、版本、打包、部署、运行和监控软件！\n","permalink":"https://devopschina.org/blog/how-to-become-a-devops-engineer-in-six-months-or-less/","tags":["DevOps","职业成长"],"title":"如何在六个月内成为一名合格的 DevOps 工程师"},{"categories":["文档"],"contents":" 社区译者：王英伟-北京\n  审校：刘征\n  原作者： Google SRE\n  原文地址：http://g.co/SiteReliabilityWorkbookMaterials\n  英文原档案本地下载：[下载](/doc/Google-Postmortem Checklist.docx)\n 第一部分 1-1 事故数据收集  1、概要描述受到的影响 2、影响范围澄清  2.1、受影响的用户 2.2、受影响的区域 2.3、受影响的客户   3、严重性分类澄清 4、事故完整的 MTTx 时间线跨度度量  1-2 根因分析  1、充分说明所有导致根本原因发生的细节 2、使用 5 why 或者其他根因技术工具确保进行深度的分析 3、确定事件触发因素 4、决定实践相关的根因类型  1-3 经验教训 \u0026amp; 设计行动计划  1、调研那些地方进展顺利，那些方面做得不好，那些方面属于运气好 2、利用经验教训确定下一步的行动事项 3、确保每条行动事项都在跟踪系统中都有一个跟踪单（如 Jira 中的 Bug 单） 4、确保涵盖两个关键的类型：缓解 和 预防  第二部分 - 行动事项检查单  1、行动项是否是都是可实现的，并获得了 PO 产品负责人的检查确认？ 2、你是否考虑过改善 预防 和 解决时间 的方法？ 3、你是否考虑过其它相似性的（或者相似事故）事故，以及相关的可参考行动计划？ 4、你是否考虑过如何用自动化的方式阻止人为失误？ 5、你的事后分析清单是否至少有一个关键级或者高优先级的行动项？如果没有，利益干系人是否可接受降低了之后的风险？ 6、你是否与责任小组（负责人）就执行的行动项进行了交流？  第三部分 - 评审/审批/社交化  1、你的事后分析清单是否按照团队的正常通过了评审/审批？ 2、是否删除/修改了任何指责性语言？ 3、你和初始的利益干系人共享了事后分析清单吗？ 4、你和团队共享了事后分析清单吗？ 5、是否能从仪表盘和工具中获取到你的事后分析清单？ 6、你的事后分析清单是不是无指责性的，并且专注于系统改进的？  词汇表  严重性分类：用于帮助分析事故的严重性类别 5-whys: https://en.wikipedia.org/wiki/5_Whys 触发：在时间段内事故影响产生的时间点 相似事故（同频事故）：性质相似，但可能不是完全重复的事故 概要描述：用于报告高阶的状况，比如那些浅显的产品介绍。「译者注：目标是任何人都可以看懂」 MTTx：x的平均时间（X 可以是故障的（检测|升级|缓解|解决）的时间）  ","permalink":"https://devopschina.org/blog/google-postmortem-checklist/","tags":["模板","Google","SRE"],"title":"Google 事后回顾检查清单【文档模板】"},{"categories":["翻译"],"contents":" 社区译者：李杰\n  审校：韦世滴\n  原文地址(原作者：Indrek Lasn)：https://medium.com/better-programming/2020-programming-trend-predictions-a5d6b70bec26\n 2020年马上就要到了，这听起来很疯狂。似乎2020年就像是科幻小说里的故事那么遥远，但我们在这里 \u0026mdash; 即将敲开它的大门。\n如果您对未来可能给编程世界带来什么感到好奇，那么读这篇文章就对了。我也有可能错了 –\u0026ndash; 所以请不要盲目的相信我 \u0026mdash; 但这就是我认为会发生的事情。我无法预测未来，但我可以做出有根据的猜测。\n“预测未来的最好方法就是创造它。” \u0026mdash;\u0026ndash; 亚伯拉罕·林肯\nRust 将会成为主流 Rust 是一种多范式的系统编程语言，专注于安全性 \u0026mdash; 尤其是并发的安全性。Rust 在语法上与 C++ 类似，但它旨在提供更好的内存安全性的同时保持高性能。\n我们已经看到了 Rust 编程语言四年的强劲增长。我认为2020年将是 Rust 正式成为主流的一年。虽然主流的定义通常是源于自我的解释，但我相信学校将开始将 Rust 引入他们的课程。这将创造一批新的 Rust 工程师。\nRust 已经证明自己是一门优秀的语言，并且它拥有一个充满活力和活跃的社区。随着 Facebook 在 Rust 上建立 Libra \u0026mdash; 这个 Facebook 有史以来最大的项目 \u0026mdash; 我们即将看到 Rust 真正取得的成就。\n如果你想学习一门新语言，我强烈建议学习 Rust。推荐阅读《Go Rust！》这本书开始你的 Rust 学习之旅，你会从中学到很多知识。\nGraphQL 将继续增长 现在我们的应用程序以及对数据使用的方式变得越来越复杂。这就需要一种比传统 REST API 更加优秀的解决方案，多次使用 GraphQL 的经历使我成为了 GraphQL 的忠实粉丝。\n典型的 REST API 需要从多个 URL 加载，但 GraphQL API 可以在单个请求中获取您的应用程序所需的所有数据。\nGraphQL 已经在各种规模的团队和许多不同的环境、语言中使用，它支持移动应用程序，网站和 API。\n如果您对学习 GraphQL 感兴趣，请查看我写的教程。\n渐进式 Web 应用程序 渐进式 Web 应用程序（PWA）是一种通过将 Web 的最佳功能与移动应用程序的顶级特性相结合来构建应用程序的新方法。\n相比于原生平台的开发人员，Web 开发人员的数量要多的多。我相信一旦大公司意识到他们可以重新利用他们的 Web 开发人员来制作渐进式网页应用程序，将来将会产生大量的 PWA 开发人员。\n当然，大型公司需要一段时间才能适应，这对于技术来说是再正常不过的。\n这部分开发工作通常会划入前端开发的范畴，因为它的主要交互方式是与 Web Workers API（Native Browser API）进行交互。\n纯原生的 Web 应用程序将越来越艰难。越来越多的人开始认识到，编写一个跨平台的 PWA 程序可以在减少工作量的同时产生更多价值。\n今天是开始了解更多 PWA 的完美日子，从这里开始。\n网页内嵌程序将迎来曙光 WebAssembly（缩写为 Wasm）是一种基于概念机的机器语言。它非常轻便，可以用于编译 C，C++ 和 Rust 等高级语言。Wasm 还支持在 Web 上部署客户端和服务器应用程序。PWA 也可以使用 Wasm 来编写。\n换句话说，WebAssembly 是一种将 JavaScript 技术与更多级别技术相结合的方法。请想象一下在 React 应用程序中使用 Rust 图像处理库 –\u0026ndash; Wasm 将上述设想变为现实。\n众所周知性能的重要性，随着数据量的增长，保持良好性能将更加困难。这也正是 C++ 或 Rust 等底层语言发挥作用的时候。我们将看到越来越多的大公司开始采用 Web Assembly。\nReact 将继续统治 React 是迄今为止最受欢迎的前端开发 JavaScript 库。构建 React 应用程序很有趣也很容易。就构建应用程序的经验而言，React 团队和社区已经做了出色的工作。\n我曾经使用过 Vue，Angular 和 React，我认为它们都是很棒的框架。但是，框架的目标是完成工作，所以完成工作是最重要的事情。争论什么框架是“最好的”是完全没有意义的。选择一个框架并将你所有的精力用于完成工作才是正途。\n如果您有灵感，请从此列表中选择一些内容并立即开始构建！\n赌 JavaScript 就对了 我可以充满信心地说，2010年是 JavaScript 的十年。我们已经看到了 JavaScript 的巨大增长，并且它似乎没有放缓。\nJavaScript 开发人员曾被称为“不是真正的开发人员”。可事实上 JavaScript 是任何大型科技公司的核心，例如 Netflix，Facebook，Google 等等。因此，JavaScript 作为一种语言与任何其他编程语言一样合法。人们应以成为 JavaScript 开发人员为荣。毕竟，JavaScript 社区已经构建了一些很酷且具创新性的东西。\n几乎所有网站都在某种程度上使用了 JavaScript。有多少个网站呢？上百万个！\n现在是成为 JavaScript 开发人员的最佳时机。工资正在上涨，社区一如既往地活跃，就业市场巨大。如果你对学习 JavaScript 很感兴趣，那么我推荐“你不懂 JS”系列丛书。\n我之前写过关于 JavaScript 流行的文章 - 你也应该读一读。\n我是否落下了很酷的项目？让我们知道哪些项目或语言值得更多的关注和爱戴！\n","permalink":"https://devopschina.org/blog/2020-programming-trend-predictions/","tags":["Rust","React"],"title":"2020年及未来的软件编程趋势预测"},{"categories":["翻译"],"contents":" 社区译者：张洁\n  审校：韦世滴\n  原文地址(原作者：Conor Delanbanque)：https://opensource.com/article/19/7/how-transition-career-devops-engineer\n DevOps 工程师是一项热门职业，有很多赞誉。无论您是在毕业后寻找第一份工作，还是希望借助您以前的行业经验，寻求机会重新学习，本指南能够帮助您采取正确的步骤成为 DevOps 工程师。\n让自己沉浸其中 首先，了解 DevOps 的基础知识、实践和方法。在开始使用工具之前，先了解 DevOps 背后的“原因”。DevOps 工程师的主要目标是在整个软件开发生命周期（SDLC）中提高速度并保持或提高质量，以提供最大的业务价值。您可以阅读文章，观看 YouTube 视频，并前往当地的 Meetup 小组或会议 \u0026mdash;\u0026mdash; 成为受欢迎的 DevOps 社区的一员。在那里您将可以当面向那些社区成员成功或是失败的经验中学习。\n考虑你的背景 如果您具有从事技术工作的经验，例如软件开发人员，系统工程师，系统管理员，网络运营工程师或数据库管理员，那么您已经拥有了广泛的视野和有用的经验，可以帮助您在未来担任 DevOps 工程师。如果您是刚刚完成计算机科学或任何其他 STEM 领域的学位后开始职业生涯，那么您将在此过渡期间需要一些基本跳板。\nDevOps 工程师角色涵盖广泛的职责。以下是企业最有可能使用它们的三种方式：\n  偏爱开发的 DevOps 工程师，担任构建应用程序工作。他们利用持续集成/持续交付（CI/CD），共享存储库，云和容器作为日常工作的一部分，但他们不一定负责构建或实施工具。 他们了解基础架构，并且在成熟的环境中，能够将自己的代码推向生产环境。\n  偏爱运维的 DevOps 工程师，可以与系统工程师或系统管理员进行比较。他们了解软件开发，但不会用他们日常的主要精力用于构建应用程序。相反，他们更有可能支持软件开发团队将原有手动流程自动化，并提高人员和技术系统的效率。这可能意味着分解遗留代码并使用较少繁琐的自动化脚本来运行相同的命令，或者可能意味着安装，配置或维护基础架构和工具。 他们确保为任何需要它们的团队安装和使用正确的工具。他们还通过教他们如何利用 CI/CD 和其他 DevOps 实践来帮助团队。\n  **网站可靠性工程师（SRE）**就像解决运营和基础设施问题的软件工程师。SRE 专注于创建可扩展，高可用且高可靠的软件系统。\n  在理想的世界中，DevOps 工程师将了解所有这些领域; 这在成熟的科技公司中很常见。然而，顶级银行和许多财富500强企业的 DevOps 职位通常会偏向开发或运维。\n要学习的技术 DevOps 工程师需要了解各种技术才能有效地完成工作。无论您的背景如何，作为 DevOps 工程师请从使用和理解的基础技术入手。\n操作系统 操作系统是一切系统运行的土壤，拥有基础知识非常重要。Linux 系统是您最有可能每天使用的操作系统，尽管有些组织使用 Windows。要开始使用，您可以在家中安装 Linux，在那里您可以随心所欲地打破规则并一直学习。\n脚本 接下来，选择一种语言来学习脚本。有很多可供选择，包括 Python，Go，Java，Bash，PowerShell，Ruby 和 C/C++。 我建议从 Python 开始;因为它相对容易学习和解释，并且是最受欢迎的语言之一。Python 通常是为了遵循面向对象编程（OOP）的基础而编写的，可用于 Web 开发，软件开发、创建桌面 GUI 和业务应用程序。\n云 在 Linux 和 Python 之后 ，我认为接下来要研究的是云计算。基础设施不再留给“运维人员”，因此您需要接触云平台，如亚马逊网络服务，Azure 或谷歌云平台。我从 AWS 开始，因为它拥有大量免费学习工具，作为开发人员AWS可以帮助您在运营、甚至面向业务组件方面少走弯路。事实上，您可能会被庞大工具淹没。可以考虑从 EC2，S3 和 VPC 开始，看看你想从那里走向哪里。\n编程语言 如果您对软件开发充满热情并参与 DevOps，请继续提高您的编程技能。DevOps 中有一些优秀、并且被广泛使用的语言与脚本语言相同：Python，Go，Java，Bash，PowerShell，Ruby 和 C/C++。您还应该熟悉 Jenkins 和 Git/GitHub，并会 CI/CD 过程中经常使用它们。\n容器技术 最后，开始学习使用 Docker 和编排平台（如 Kubernetes）等工具进行容器化。这些工具都有大量的免费在线学习资源，大多数城市都有本地的 Meetup 小组，您可以在友好的环境（比萨和啤酒！）中向有经验的人学习。\n还有哪些 如果您的开发经验较少，您仍然可以发挥对自动化的热情，提高效率，与他人协作以及改进您的工作来参与 DevOps。我仍然建议学习上述工具，但不太强调编码/脚本语言。反而了解 SaaS，PaaS，云平台和 Linux 将非常有用。您可能正在设置工具并学习如何构建具有弹性和容错性的系统，并在编写代码时利用它们。\n寻找 DevOps 工作 求职过程会有所不同，具体取决于您是否一直从事科技工作，并且正在进入 DevOps，亦或您是刚开始职业生涯的毕业生。\n如果你已经在从事技术工作 如果您正尝试从一个技术领域转变为 DevOps 角色，那么首先要发掘当前公司的机会。你可以和其他团队一起工作吗？尝试影响其他团队成员，寻求建议，并在不离开当前工作的情况下获得新技能。如果无法做到这一点，您可能需要转移到另一家公司。如果您可以学习上面列出的一些实践，工具和技术，那么您将在面试中展示相关知识。关键是要诚实，不要让自己失败。大多数招聘经理都知道你不知道所有的答案; 如果你能展示你所学到的东西，并解释你愿意学习更多东西，你应该有机会获得 DevOps 工作。\n如果你正在开始你的职业生涯 适用于雇用初级 DevOps 工程师的公司的开放机会。不幸的是，许多公司表示他们正在寻找经验丰富的工程师，并建议您在获得一些经验后重新申请。“我们想要经验丰富的工程师”多么令人沮丧，却非常典型，似乎没有人愿意给你第一次机会。\n然而，并非一切都让人感到沮丧;仍然有一些公司专注于直接从大学培训和提升毕业生。例如，我工作的 MThree 聘请了应届毕业生并培训他们八周。当他们完成培训时，参与者可以充分了解整个 SDLC，并很好地理解它在财富500强环境中的应用。毕业生被聘为 MThree 客户公司的初级 DevOps 工程师 \u0026mdash;\u0026mdash; MThree 在前18至24个月内支付全职工资和福利，之后他们作为直接雇员加入客户。这是弥合从大学到职业技术的差距的好方法。\n总结 转型为 DevOps 工程师的方法很多。这是一条非常有益的职业路线，能让你保持参与和挑战 \u0026mdash;\u0026mdash; 并提升你的赚钱的能力。\n","permalink":"https://devopschina.org/blog/how-transition-career-devops-engineer/","tags":["DevOps","职业成长"],"title":"职业生涯如何转变成DevOps工程师"},{"categories":["翻译"],"contents":" 社区译者：熊小龙(DragonXiong)\n  审校：阿超（Frank Li）\n  原文地址(原作者：Shivam Arora)：https://www.simplilearn.com/devops-interview-questions-answers-article \n 直到最近，开发工程师还常常孤立的工作，将他们的知识和技能限制在编码和测试上，而运维工程师则专注于交付和基础设施配置工作，对软件开发的知识很少。\n然而，随着IT领域的快速增长和技术进步，大多数IT公司的传统方法已经发生了模式转变。DevOps文化虽然还处于起步阶段，但它作为IT开发和运维之间的完美桥梁，近年来已经成为软件开发的一种流行方法。\n一篇名为《DevOps招聘热潮》的文章称，到2019年，《财富》1000强企业中预计将有80%采用DevOps。Indeed.com进行的一项调查显示，美国DevOps工程师的平均年薪约为123,439美元。\n如果您已经开始交叉培训，为IT行业的开发和运维角色做准备，那么您就知道这是一个具有挑战性的领域，需要进行一些真正的准备才能进入。下面是一些最常见的DevOps面试问题和答案，它们可以帮助您在此行业准备DevOps角色转型。\n1. 你对DevOps了解多少? 你的答案必须简单明了。首先解释DevOps在IT行业中日益增长的重要性。讨论这种方法的目标是如何协同开发和运维团队的工作，以最小的故障率加速软件产品的交付。包括DevOps是如何成为一种增值实践的，开发和运维工程师在整个产品或服务生命周期中携手合作，从设计阶段到部署阶段。\n2.为什么DevOps在过去的几年里变得如此重要? 在讨论DevOps日益流行之前，先讨论一下当前的行业场景。首先举几个例子，说明Netflix和Facebook等大公司是如何投资DevOps来实现应用程序的自动化和加速部署，以及这如何帮助它们发展业务。以Facebook为例，您将指出Facebook的持续部署和代码所有权模型，以及这些模型如何帮助它扩展，同时确保体验的质量。数百行代码的实现不会影响质量、稳定性和安全性。\n您的下一个用例应该是Netflix。这家流媒体和点播视频公司也采用了类似的做法，采用了完全自动化的流程和系统。提到这两个组织的用户基础:Facebook有20亿用户，Netflix向全球1亿多用户提供在线内容。这些都是DevOps如何帮助组织确保更高的发布成功率、减少bug修复之间的前置时间、通过自动化简化和持续交付，以及全面降低人力成本的很好的例子。\n3.哪些是最流行的DevOps工具?你有使用这些工具的经验吗? 更流行的DevOps工具包括:\na. Selenium\nb. Puppet\nc. Chef\nd. Git\ne. Jenkins\nf. Ansible\ng. Docker\n想要掌握所有这些****DevOps工具吗?\n详细描述你有信心的任何工具，它的能力是什么，以及为什么你更喜欢使用它。例如，如果您精通Git，您可以告诉面试官Git是一个分布式版本控制系统(VCS)工具，它允许用户跟踪文件更改，并在需要时恢复到特定的更改。讨论Git的分布式架构如何为它提供了一个附加的优势，开发人员可以在本地进行更改，并在本地Git存储库中保存整个项目历史，以后可以与其他团队成员共享。\n既然您已经提到了VCS，那么准备好回答下一个显而易见的问题吧。\n4. 什么事版本控制？为什么应该使用VCS？ 定义版本控制，并谈谈此系统如何记录对一个或多个文件所做的任何更改，并将其保存在集中存储库中。VCS工具将帮助您回忆以前的版本并执行以下操作:\n· 检查一段时间内所做的更改，并检查哪些有效，哪些无效。\n· 将特定文件或特定项目还原为旧版本。\n· 检查由于特定更改而发生的问题或错误\n使用VCS为开发人员提供了同时处理特定文件的灵活性，所有修改都可以在以后逻辑上组合起来。\n5.敏捷和DevOps之间有区别吗?如果是，请解释。 作为DevOps工程师，像这样的面试问题是很有必要的。首先描述DevOps和敏捷之间的明显重叠。尽管DevOps的实现始终与敏捷方法保持同步，但两者之间有明显的区别。敏捷的原则与软件的无缝生产或开发相关联。另一方面，DevOps处理开发，然后部署软件，确保更快的周转时间、最小的错误和可靠性。\n如果您正准备成为高级DevOps角色，请准备这些特定的Chef DevOps面试问题。\n6.为什么配置管理过程和工具很重要? 谈谈正在开发的每个软件或测试件的多个软件构建、发布、修订和版本。接下来解释存储和维护数据、跟踪开发构建以及简化故障排除的必要性。不要忘记提及可用于实现这些目标的关键CM工具。谈谈Puppet、Ansible和Chef等工具如何帮助在多个服务器上自动化软件部署和配置。\n7.如何使用Chef作为CM工具? Chef被认为是业界首选的CM工具之一。例如，Facebook将其基础设施和后端IT迁移到了Chef平台。解释Chef如何通过自动化流程帮助您避免延迟。脚本是用Ruby编写的。它可以与基于云的平台集成并配置新的系统。它为基础设施开发提供了许多库，这些库稍后可以在软件中部署。由于其集中管理系统，一个Chef服务器就足够作为部署各种策略的中心。\n8.您如何解释“基础设施即代码”(IaC)的概念? 将IaC作为一个概念来讨论是一个好主意，它有时被称为可编程的基础设施，其中基础设施与任何其他代码的理解方式相同。描述管理基础设施的传统方法如何退居二线，以及手动配置、过时的工具和自定义脚本如何变得越来越不可靠。其次，强调IaC的好处，以及如何使用IaC以更快、更安全、更容易的方式实现对IT基础设施的更改。包括IaC的其他好处，如对基础设施配置应用常规单元测试和集成测试，以及维护最新的基础设施文档。\n如果你已经通过了Amazon Web Services (AWS)的认证，并且正在面试诸如AWS认证的DevOps工程师这样的理想职位，以下是一些AWS DevOps面试问题，你必须准备好:\n9.AWS在DevOps中扮演什么角色? 当在面试中被问到这个问题时，你可以直截了当地说，AWS是亚马逊提供的一项基于云的服务，通过无限的计算能力和存储来确保可伸缩性。AWS授权IT企业开发和交付复杂的产品，并在云中部署应用程序。它的一些关键服务包括Amazon CloudFront、Amazon SimpleDB、Amazon Relational Database(关系数据库服务) 和Amazon Elastic Computer Cloud。讨论各种云平台，强调您过去使用云基础设施处理过的任何大数据项目。\n10.IaC是如何使用AWS实现的? 首先谈将命令写入脚本文件并在部署之前在单独的环境中测试它们的古老机制，以及IaC如何替代这种方法。与为其他服务编写的代码类似，在AWS的帮助下，IaC允许开发人员使用JSON或YAML等格式，以描述性的方式编写、测试和维护基础设施实体。这样就可以更容易地开发和更快地部署基础设施更改。\n您具备成为DevOps工程师的技能吗?这里有40个Devops认证考试问题。参加这个免费的练习测试，了解你现在的水平!\n作为DevOps工程师，深入了解流程、工具和相关技术是必不可少的。您还必须对产品、服务和系统有一个全面的了解。如果您的答案与我们上面提供的答案相匹配，那么您将在未来的DevOps面试中处于表现良好。祝你好运！如果您正在寻找特定的DevOps面试问题的答案，而这些问题在这里没有提到，请在下面的评论中提问。我们的DevOps专家将帮助您设计完美的答案。\n观看这段关于DevOps面试问题和答案的视频\nDevops Interview Questions | DevOps Interview Questions And Answers | DevOps Tutorial | Simplilearn\nAbout the Author Shivam Arora\nShivam Arora is a Senior Product Manager at Simplilearn. Passionate about driving product growth, Shivam has managed key AI and IOT based products across different business functions. He has 6+ years of product experience with a Masters in Marketing and Business Analytics.\n","permalink":"https://devopschina.org/blog/devops-interview-questions-answers-article/","tags":["DevOps","面试","interview"],"title":"10个最受欢迎的DevOps面试问题和答案"},{"categories":null,"contents":"2019中国DevOps社区年会 大会简介 会后总结和回顾 点此处查看会后总结和回顾文章。\n","permalink":"https://devopschina.org/event/2019-hangzhou-summit/","tags":null,"title":"2019中国DevOps社区年会"},{"categories":["翻译"],"contents":" 社区译者：付文新\n  审校：韦世滴\n  原文地址(原作者：Tim Little)：https://medium.com/kudos-engineering/increasing-resilience-in-Kubernetes-b6ddc9fecf80 \n Kubernetes 有两大关键特性：高可用性和弹性。但是当 Kubernetes 集群出现不稳定的时候，我们能做什么呢？眼睁睁看着自己的巨轮沉入深海？\nKubernetes 节点问题 我们在使用谷歌 Kubernetes 引擎集群（GKE）时常会遇见这个问题：集群中的 Kubernetes 节点经常性的宕机。\n其影响是调度问题节点的容器变得无法响应，我们的监控系统开始大量发送 SLO 和错误预算消费的告警邮件。想更多的了解什么是 SLO 和错误预算告警，以及我们是如何监控的，请查看我之前的一篇博文。\n通过运行 gcloud container operations list 检查命令，我们发现节点会每隔几小时就尝试自动修复。\n然而当我们查看 Stackdriver 日志，我们发现了大量的日志，这使得定位问题变得如同海底捞针。\n因此我们申请了 Google 的支持，希望可以帮助我们找到问题的根本原因。\n不幸的是由于时区差异和我们的账号使用的是遗留支持包的原因，我们每隔24小时才能看到一条 Google 反馈的信息。\n最终这个问题耗尽了我们 Kubernetes 中一系列服务的错误预算，因此在真正的 SRE 风格中，我们致力于提高 Kubernetes 集群和 Istio 服务网格的弹性。\n增加 kubernetes 服务的弹性 我们首先深入研究了 Kubernetes 集群的设置及运行在它之上的服务，然后确定我们可以增加弹性的范围，主要目的是减少当单个节点无法响应时产生的影响。\n 副本数量和 pod 在不同节点的分布  我们能够改进提升的第一个方面就是增加 Kubernetes Deployment 的副本数量。我们在 Kudos 上部署了采用微服务架构的服务，这些服务都特别微小，没有状态，特别适合水平扩展。\n然而有些 Deployment 只运行一个 pod 上，如果这个 pod 刚巧运行在发生问题的节点上，我们的服务就会中断。因此我们修改了 Deployment，运行至少3个副本以提高弹性。\n当时我们只有3个节点（现在14个），这导致了另外一个问题：有时 Kubernetes 会调度所有 pod 到同一个节点上。\n因此我们使用了 Kubernetes 的一个名为 Pod AntiAffinity 的功能特性：如果某个节点已经包含具有相同标签（例如：app=\u0026lt;service-name\u0026gt;）的 pod，该特性将指示调度程序把该节点标记为不可调度。\naffinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - \u0026lt;service-name\u0026gt; topologyKey: \u0026#34;kubernetes.io/hostname\u0026#34; 添加了这些内容并重新部署了所有服务之后，我通过运行 kubectl\tget\tpods\t-o customcolumns=’NAME:.metadata.name,NODENAME:.spec.nodeName 命令验证了 pod 被调度到不同的节点上。\n现在如果我们的一个节点再次宕机，我们也只损失了部署的3个 pod 中的一个，我们的服务仍然可用。\n 就绪探针与预停命令  我们注意到另一个问题是当节点被修复时，Kubernetes 会在节点准备就绪之前就开始发送流量。在升级 Kubernetes 节点池的时候也遇到过类似问题，但我们从未深究其因。\n经过 Google 一番之后，我们发现一篇关于零停机滚动更新的博客。这篇博客的主要内容之一是关于把 pod 标记为终止，并从负载均衡中将其删除的异步特性。\n 这种重新配置是异步进行的，因此不能保证其按照正确的顺序，从而导致不少请求被分发到终止的 pod 上，进而致使请求崩溃。\n 从此以后，我们在所有的服务上都增加了Readiness probes(就绪探针)，并增加preStop(预停)命令：该命令会等待10秒后终止，以允许这些少数连接仍然可用。\nreadinessProbe: httpGet: path: /readiness port: 8080 initialDelaySeconds: 15 lifecycle: preStop: exec: command: [\u0026#34;/bin/sh\u0026#34;,\u0026#34;-c\u0026#34;,\u0026#34;sleep 10\u0026#34;]  Istio 水平自动伸缩  随着 Kubernetes 的进一步稳定，我们注意到集群中另一个单点故障：Istio。\n我们把 Istio 当做谷歌 Kubernetes 引擎（GKE）的附加组件使用，这使得我们可以使用 Istio，并且不需要额外的操作开销来管理 Istio 的控制面板。\nIstio 使我们能够按路线分发流量到网络中的任意服务中去，而不需要每个服务都有一个公共的 IP 地址。\n它通过入口网关（Ingressgateway）来实现这一点，该网关是一个位于网络边缘的代理（Envoy）网关，并且连接到 Google 的负载均衡器上，以便获取访问外部网络的权限。\n我们遇到的问题是谷歌 Kubernetes 引擎（GKE）附加组件默认的 Istio 只在一个 pod 中部署入口网关（Ingressgateway）。这就意味着一旦该节点忽然宕机，我们就无法访问网络中的所有服务。\n这肯定不是理想方案，因此我们研究了下 Istio 的设置，结果发现 Google 早就意识到这一点，可以通过部署 HorizontalPodAutoscaler 来修改 Istio 的控制面板。为此，我们需要用这个命令 kubectl edit -n istio-system Deployments/istio-telemetry 向 Istio 控制面板组件添加资源请求，之后在容器中添加以下内容：\nresources: requests: cpu: 100m 这使得 HorizontalPodAutoscaler 可以检测 Pod 的 CPU 利用率，并相应的进行伸缩或扩展。就如同我们之前为其他服务所做的一样，我们还编辑了 HorizontalPodAutoscaler，使其至少有3个副本在运行。\n根源分析 在解决弹性问题的期间，我们一直和 Google 的支持团队保持联系。\n支持团队建议我们深入查看下 Kubernetes 的节点，并怀疑这是一个资源耗尽的问题。\n在对节点进行了一些故障排除之后，我们发现一些节点上的进程 ID 中出现了泄露，\u0026lt;defunct\u0026gt; 进程树中数以千计的进程没有被正确终止。\n检查了父进程 ID 之后，我们发现了问题所在。\n该3491355 进程是我们其中的一个容器，它用来转换 HTML 页面到 PDF，使用的是 Google 的 Chrome 实例来实现这一点。\n这个无头服务有一个名为 /readiness 用来检查 Google Chrome 版本的程序，但是该程序只抓取了版本信息文件，cat进程并没有被正确的结束。\n我们之后修改了程序 readiness，并重新部署了 pdfgenerator 服务，然后我们看到运行该服务的节点中 PID 数量大幅减少。\nKubernetes 开发团队预见了这个问题，并在1.14 版本中引入了 PID 限制。可惜的是我们生产环境运行的1.13版本，没能够赶上这个变化。\n结论 在这些问题背后，我们学到了大量关于 Kubernetes 和 Istio 的知识。我们更新了自己的微服务模板，使部署到我们集群中的默认微服务更有弹性，而且扩展了集群以帮助支持新服务。\n如果你对这些都感兴趣，为什么不考虑加入Kudos？\n","permalink":"https://devopschina.org/blog/increasing-resilience-in-kubernetes/","tags":["kubernetes","HA"],"title":"如何提高Kubernetes的弹性"},{"categories":["翻译"],"contents":" 社区译者：马杰-天津\n  原文地址：https://medium.com/better-programming/the-differences-between-a-junior-mid-level-and-senior-developer-bb2cb2eb000d\n 你如何更上一层楼？ 作为一名初级、中级或高级的开发人员，并不仅仅意味着他们在编程年限长短的差异。有时候初级开发人员的年龄甚至可能比高级开发人员还要大。这一切都取决于技术。这并不是说高级开发人员必须是所有方面的专家，但毋庸置疑高级开发人员肯定远比初级和中级开发人员能更加熟练。\n除了编码技能使高级开发人员与中级和初级开发人员区别开来，那还有什么区别呢？\n 知识  显然，高级开发人员比初级和中级开发人员拥有更多的知识。掌握设计模式，架构，自动化测试，性能，安全性等知识是初级开发人员与中级和高级开发人员缩小差距的好方法。\n了解软件开发中应该如何做是很重要的。但是仅仅知道这些东西并不能使你成为一名高级开发人员。知识并不是开发者之间最大的区别，它只是其中一个因素。\n 编码  尽管大多数人认为，编码并不是与计算机进行对话。编码只是将人与人的交流用来指导计算机，并且最终代码被编译成为0和1。\n代码能让将来使用它的其他开发人员顺利理解，即使从未见过代码的新团队也应该能够打开代码后就开始处理新功能或错误修复，这是初级开发人员和高级开发人员之间的巨大差异。\n我没有考虑中级开发人员，因为在编码技能方面，中级开发人员是一个灰色地带。显然，它介于初级和高级之间。它可能更倾向于高级方面。这主要与经验有关，因为中级开发人员至少经历过一次完整的开发周期。他们犯了许多最低级的错误，并从中吸取了教训。\n如何识别初级开发人员？ 初级开发人员是缺乏经验的。有些刚毕业刚刚开始全职开发工作。他们的心态通常是让代码运行起来就行。他们认为能运行的程序就是好的程序。\n编写精简的代码是很困难的。这是初级开发人员所做不到的事情。初级开发人员会编写一些奇怪的代码，通过一行复杂抽象的代码就辨别出是一个初级开发人员。这是初级开发人员想向其他开发人员炫耀他们可以编码的多好，但是这是错的。初级开发人员专注于计算机如何运行代码而牺牲了人性化的一面。\n高级开发人员高明在哪？ 当你查看高级开发人员的代码时，你可能会想：这就是全部吗？代码的其余部分在哪里？高级开发人员编写简单，直接，甚至是愚蠢的代码。这才是开发人员在编程时可以拥有的最大品质之一。一位资深开发人员遵循 KISS 原则：保持简单，愚蠢（Keep it simple, stupid）。\n高级开发人员以不同于初级开发人员的方式思考他们的代码。高级开发人员会考虑代码编写的可维护性和可伸缩性。这是一种与初级开发人员完全不同的心态，高级开发人员考虑到那些使用他代码的人，而初始开发人员只让代码能正常运行。\n其实不仅仅是拼编码技巧 除了编码技巧，还有一些其他的因素能展示出你是什么层级的开发人员。\n一般来说，初级开发人员执行最简单的任务或影响较小的任务，他们不做任何架构设计。中级开发人员也没有设计解决方案，他们只是执行任务。与初级开发人员的不同之处在于，只要按照常规分配给他们任务，他们就可以在不怎么监督的情况下完成这些任务。而高级开发人员可以完全自主的开发应用程序。\n这并不意味着高级开发人员在此过程中没有任何问题。每个开发人员每天都有很多问题，这是常态。对高级开发人员来说也并没有什么不同。但不同之处在于，高级开发人员知道如何提出正确的问题以及如何处理这些问题。中级开发人员可以在相对常规的任务中提出正确的问题，但在更复杂的任务中需要帮助。\n高级开发人员却永远不会迷失，他们知道如何正确的跟进问题。这并不是说高级开发人员不能向其他开发人员寻求帮助。有时候，最好的方法就是向在该领域有经验的其他开发人员寻求帮助。\n中级开发人员也应该能够提出正确的问题，只要他没有被分配到需要深知识水平的高度复杂的任务。\n不要寄希望于一个初级开发人员能够立即提出正确的问题。由于初级开发人员缺乏经验，他们需要更有经验的开发人员的指导。初级开发人员需要获得必要的资源大力促进他们找到正确的发展方向。\n如何进入更高段位？ 作为开发人员，我们都希望自我提升并变得更好。但是，进入到更高层级需要哪些步骤呢？\n 初级到中级  由于初级开发人员缺乏经验，因此至少要经历几次完整的开发周期是非常重要的。通过这种方式，你将掉入到大量陷阱中并从中学习如何在下次避开它们。\n在编码时，你应该学习如何编写简单的代码。替下一个将要处理这段代码的人考虑一下。你还应该学习如何调试，因为这将使你更好地了解程序运行过程中发生的情况。\n此外，最好用实践的方式去学习架构，性能，安全性等。缩小达到中级所需的知识差距。\n 中级到高级  从中级到高级可能会非常困难。一些开发人员在整个职业生涯中只能保持在中等水平。\n高级开发人员知道哪些地方可以切掉，哪些地方不应该切掉。这些都是过去犯过错误的教训。\n如果你想要达到高级水平，你必须准备好接受没有人知道如何解决的任务。你应该了解的不仅仅是如何完成工作。作为高级开发人员，你的工作也是帮助经验不足的开发人员。当他们不知道如何做某事时，你就是他们的后备力量。\n高级开发人员掌握他们的技术堆栈可能并不令你感到惊讶。比编码技巧更重要的是了解你所在公司内使用的所有工具和应用程序。\n结论 初级，中级和高级开发人员之间的差异并非全部来自经验的多少。毋庸置疑高级开发人员比初级和中级开发人员更熟练。但知识并不是最重要的因素。\n与初级开发人员相比，高级开发人员编写代码更容易，并且具有不同的思维方式。除了编程技术，知道要问什么问题以及如何跟进这些问题是至关重要的。只有具有丰富经验的高级开发人员才知道如何在所有情况下做到这一点。\n要成为初级开发人员，应该专注于编写简单的代码并经历多个开发周期。要从中级到高级开发人员，应该专注于学习而不仅仅是日常任务。你应该愿意承担最艰巨的任务并成为技术领域的领导者。另外，高级开发人员要担当缺乏经验的开发人员的后备力量。\n我留下马丁·福勒的一句话：“任何傻瓜都能写计算机能理解的代码，优秀的程序员编写人类能够理解的代码。”\n","permalink":"https://devopschina.org/blog/the-gap-between-programmers/","tags":["开发","成长"],"title":"初、中和高级程序员究竟差在哪？"},{"categories":["调查"],"contents":"本文是中文版《2019年加速度DevOps状态调查》问卷。如果你还没有填写该问卷的话，可以在线上填写英文版，点击这个链接 https://bit.ly/2UzLMH2 ，进入问卷调查网站。本文可以作为你的帮助文档。\n 译者团队：刘征、张晔、刘頲、朱婷、王英伟、王虹、李建芳、沈越飞、井建宇、申屠欣欣\n 本文由以上翻译团队经过两周的时间，在业余时间翻译完成，如果对本文有任何改进建议请发邮件到 info@DevOpsChina.org\n发布本文的另外一个原因：作为历时6年，被称之为DevOps界之科学的调查研究，我们可以透过这套问卷，洞察如何用问卷的方式定量的度量DevOps的现状。对于已经实施了多年DevOps企业，本问卷可谓是一道营养丰富的大餐。\n 下面是2019年DevOps状态调查问卷的简体中文版译文。\n第一部分 欢迎参加2019年全球DevOps全球行业调查。\n 我们有兴趣了解您的工作方式以及工作环境。  答案并没有对错。  如果您不知道答案，可以选择“我不知道或不适用”，您的作答将被忽略。  非常感谢您花时间帮助我们去探索那些能使技术进步的秘密！\n1. 您的组织主要属于哪个行业？\n 教育 能源 金融服务 政府 医疗保健和制药 工业与制造业 保险 媒体/娱乐 非盈利 零售/消费品/电子商务 技术 电信 其他。请明确说明： [____]  2. 有多少员工在您的组织里工作？\n 1-4 5-9 10-19 20-99 100-499 500-1,999 2,000-4,999 5,000-9,999 10,000+ 我不知道  3. 你们的服务器上都部署了哪些操作系统？\n Windows 2003 / 2003R2 Windows 2008 / 2008R2 Windows 2012 / 2012R2 Windows 其他 Linux Debian / Ubuntu变种 Linux Enterprise Linux变体（RHEL，Oracle，CentOS） Linux Fedora Linux SUSE Linux Enterprise Server Linux OpenSUSE Linux Arch Linux其他 其他的UNIX FreeBSD / NetBSD / OpenBSD系统 AIX Solaris 其他  4. 在过去一年中，关于下列绩效指标，您的组织实现的程度如何？\n 您组织的整体表现 您组织的整体盈利能力 主要产品的相对市场份额 客户数量增加  （表现远低于目标 表现低于目标 略低于目标 达到了目标 略高于目标 表现高于目标 表现远高于目标 不适用或我不知道）\n5. 我们也有兴趣了解其他一些目标。 选择指示您的组织在过去一年中如何针对以下目标执行的选项\n 产品或服务的数量 运营效率 消费者满意度 所提供的产品或服务的质量 实现组织的/使命的目标 通过其它的方面向外部各方证明了贵组织实现预期成果  （表现远低于目标 表现低于目标 略低于目标 达到了目标 略高于目标 表现高于目标 表现远高于目标 不适用或我不知道）\n6. 我们有兴趣了解DevOps或敏捷方法是怎样在您组织的各个团队中传播的。 在这里，我们将描述我们看到过的那些常见的模式，并要求您从中选择出哪些在自己的组织中最常见方式（请选择所有适用的选项）\n  培训中心（有时也称为DOJO） - 让人们暂时脱离正常的工作惯例，以便在一段时间内学习新的工具或技术、实践甚至文化，然后再回到正常的工作环境中，目标（希望？）是：他们会坚持使用新的工作方式，甚至可能推广给其他的人。\n  卓越中心 - 一个所有专业知识都具足，然后为内部各方提供咨询的地方。\n  止步于概念证明 - 进行概念证明（PoC）项目，通常执行团队可以突破组织规范（通常是官方的规则）的羁绊，从而自由的按照所认为的最好的方式构建。然而，在PoC之后，那些付出就停滞不前了。\n  用概念证明当模板 - 也是从小规模的概念证明（PoC）项目（如上所述）开始，然后开始使用这个最初的模式在组织中的其它团队进行复制。\n  用概念证明做种子 - 也是从小规模的概念证明（PoC）开始，然后将PoC知识传播给其他团队。这是通过打散PoC（可以是第一个PoC团队，或是后续/并行的PoC团队）执行团队，并将他们派发到其他团队，去分享他们所学到的知识和实践的方式来完成的。也可以称此为轮岗，那些前PoC团队成员沉浸在其他团队中，发挥着传播新的实践和文化，并兼做导师的职责。他们可能会无限期地留在这个新的群体中，或者只是用足够长的时间来确保，他带来的新的做法是可持续的。\n  实践社区 - 在组织内培养对工具、语言或方法有共同兴趣的团体，以便在他们的彼此之间、团队之间，以及在组织内部分享他们的知识和专业技能。\n  大爆炸式 - 组织进行整体一次性的DevOps方法（当然他们要选择对其下的定义）转型，通常采用自上而下的指令。\n  自下而上或草根方式 - 那些在一线工作的小团队将资源整合在一起，然后在整个组织中，通过非官方的形式分享所取得的成功，并进行推广，而无需任何组织官方的支持或资源。\n  混搭型 - 组织实施过了上述的若干种方法，通常由于无法得到成功所需的资源和重视，只能是半途而废了。\n  第二部分 这部分涉及您的工作及其成果，以及它对您自身的影响。\n1. 在你工作的过程中，你的感受是怎样的？ 请评价您对以下陈述的同意或不同意程度。\n 我经常处于高水平的生产力 我经常能够进入一个良好的“流程”，在那里我可以完成复杂、耗时的任务，同时最大限度地减少干扰和中断。 我对我的工作很满意。 我有足够的工具和资源来完成我的工作。 我的工作很好地利用了我的技能和能力。  （强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）\n2. 对于您工作的主要应用程序或服务，变更前置时间（即：从代码提交到在生产中成功运行的过程需要的时间）是多长？\n 超过六个月 一个月到六个月之间 一周到一个月之间 一天到一周之间 不到一天 不到一个小时 我不知道或不适用  3. 对于您工作的主要应用程序或服务，您的组织在生产环境进行代码部署或向最终用户做发布的频率是什么？\n 每六个月少于一次 每一到六个月一次 每周到每月一次 每天到每周一次 每小时到每天一次 按需（每天都要进行多次部署） 我不知道或不适用  4. 对于您工作的主要应用程序或服务，当服务中断或出现影响用户Bug时（如：计划外中断、服务受损），恢复服务通常需要多长时间？\n 超过六个月 一个月到六个月之间 一周到一个月之间 一天到一周之间 一天之内 一小时之内 我不知道或不适用  5. 对于您所工作的主要应用程序或服务，对于生产变更，或向最终用户发版的变更，百分之多少会导致服务质量下降（如：服务受损或服务中断），并需要进行后续的修复工作（需要热补丁、回滚，前向修复，打补丁修复）\n 0％-15％ 16％-30％ 31％-45％ 46％-60％ 61％-75％ 76％-100％ 我不知道或不适用  6. 接下来的问题会询问可靠性，以及您和您的团队如何看待它。 请评价您对以下陈述的同意或不同意程度。 对于您所工作的主要应用程序或服务：\n 定义了明确的可用性目标（如服务级别协议/服务级别目标），这些目标在团队和客户之间达成了清晰的共识。 我知道最近一段时间实际的可用性。 在最近一段时间内，我的团队达到或超过了可用性目标。 当我们未达成可用性目标时，就会进行改进工作，也或将对调整工作的优先级。 如果使用云服务，我的团队就会借助云计算的高可用性（如：使用多个可用区）来提高可靠性。  （强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）\n7. 工作的可持续性很重要，而职场透支是一个相关的重要度量指标。您能否回答几个问题，让我们知道您的工作对您有何影响？ 请评价您对以下声明的同意或不同意程度：\n 我感觉透支很严重。 我感到筋疲力尽。 我对所从事的工作无语或愤世嫉俗。 我觉得工作效率低下。 我觉得工作应对业余的正常生活产生负面影响。 我能够完成工作并保持良好的整体状态。 我能够有效应对与工作有关的压力。 我可以在业余时间中（即，当我选择不工作时）脱离工作。  （强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）\n第三部分 当你回答以下问题的时候，请回想一下你在团队中的经历\n1. 请评价您对以下声明的同意或不同意程度：\n 如果我对我们的团队犯了错误，也不会有不良影响。 我们团队的成员能够发现问题和提出棘手的问题。 我们团队的成员不会因为差异性而互相拒绝。 对我们的团队而言冒风险是安全的。 想让我们团队的其人提供帮助并不困难。 我们团队中没有人会以任何形式故意破坏我的工作成果。 团队非常重视我独特的技术和才能。 我们的团队能够在出现冲突时解决冲突。 我们团队内部有很高的信任度。  （强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）\n2. 当你回答以下问题时，回想你是如何和你的团队合作的\n请评价您对以下声明的同意或不同意程度：\n 当我的团队成员之间存在相反的意见时，我们会互相尊重。 我可以依靠我的团队来产出高质量的成果。 我的团队提供了一个可以创新的环境。 我的团队有明确的角色和责任。 我的团队所承担的项目对我来说具有个人和专业意义。 我能够获得有效完成工作所需的必要的信息（例如，战略、新产品、组织变革，我们的优先事项和价值观）。  （强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）\n3. 回想一下你的团队是如何工作和组织的\n请评价您对以下陈述的同意或不同意程度。\n对于您使用的主要应用程序或服务：\n 为了完成我自己的工作，我不需要与团队外的人沟通和协调。 在我的团队中，我们可以对系统的设计进行大规模更改，而无需为其他团队创建重要的工作。 在我的团队中，我们可以对系统的设计进行大规模更改，而不用依赖于其他团队的大量工作。 我的团队可以根据需要独立部署和发布我们的产品或服务，而不依赖于其依赖的其他服务。 我们可以按需的进行大部分的测试，而无需等待一个集成测试环境。 在我的团队中，我们在正常工作指端中执行部署，停机时间可忽略不计。  （强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）\n4. 最后，我们想了解一下您的组织文化。\n请评价您对以下声明的同意或不同意程度：\n 我的组织氛围宜人，重视各种不同的观点。 我的组织是一个所有类型的员工（例如，所有性别，种族，文化背景）都能够完全发挥其能力的地方。 当我在组织中发言时，我的意见很受重视。  （强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）\n第四部分 这部分关于你所处环境中知识是如何供给和获取的。 让我们换个角度，告诉我们您的日常工作。\n1. 当您工作时，您会在哪里寻找信息？\n 当我需要相关知识用于解决问题时，我会频繁访问外部信息（如Stack Overflow、百度等）。 当我遇到具有挑战性的问题，需要寻找类似问题的解决方案时，我经常访问外部信息 (如Stack Overflow、百度等)。 当我处理困难的任务时，我经常和可能遇到类似问题的人沟通。 当我需要工作相关主题或问题的知识时，我经常与其他人讨论。 在处理任务时，我经常会参考内部知识库或工具来帮助找到解决方案。 当我处理具有挑战性的问题时，我经常搜索内部工具或代码库以便找到类似问题或示例的解决方案。 当我有疑问或寻找代码示例时，我经常搜索组织的源代码库 当我有疑问或遇到有挑战的问题时，我会搜索内部文档  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n2. 当您遇到问题时，您会定期检查哪些信息来源？请选择所有适用项\n 内部(组织)知识库、论坛或文档 内部(组织)代码库 Stack Overflow 网站 在线教程和视频 百度、Bing或其它类似的公开搜索引擎 外部(公共)参考文档 当面请教同事 通过电子邮件、文本或聊天工具请教同事 朋友或同行(如微信、网络兴趣组、微博等) 您自己的个人笔记 其它。请填写 以上都不是  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n第五部分 这部分关于你的角色，以及你们团队做变更的特征和模式等。\n1. 现在让我们谈谈您工作时的感受。\n无论您的正式职位是什么，让我们谈谈您所做的工作。在您的日常工作中，您负责多少个不同的角色（或工作类型）？请选择所有适用项\n 软件开发 测试 基础设施/运营 数据库管理 信息/应用安全 人员管理 项目或产品管理 文档 需求分析 用户体验 随时待命/事件响应 其它。请列出您执行的其他角色  2. 您每天在这些角色之间切换多少次？\n 不想回应 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20或以上  3. 您现在正工作在多少个项目或产品上？\n 不想回应 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20或以上  4. 您通常在一周中工作在多少个项目上？\n 不想回应 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20或以上  5. 思考下你过去3个月的工作。 请以这些记忆里的工作对以下陈述进行回应。\n我遇到过的代码，脚本，配置或系统\u0026hellip;\u0026hellip;\n 包含已知的错误，这些错误不支持新功能开发 没有足够的测试或测试覆盖率 与低下的代码质量或设计有关 取消或放弃项目后尚未进行清理 在我所在的团队中没有人有专业知识能够理解 有不完全或不正确的迁移 使用了过时的技术 文档和/或注释存在缺失、不完整或过时的情况  6. 现在思考在你的组织中的进行变更及相应流程是什么样的。\n在我的组织中\u0026hellip;\u0026hellip;\n 在实施或部署之前，必须由外部机构（例如，变更审批委员会，经理等）批准生产变更 我的组织有一个正式的流程来批准在实施或发布之前对应用程序或生产系统进行变更。 我清楚地了解批准实施​​变更的流程 我相信我能够及时通过审批流程来实施变更 对于我通常所做的各类变更，我知道每次从“提交”到“已接受”所需的步骤。 我们依靠同事的同行评审（例如代码审查或结对编程）来管理或批准变更。 我的团队遵循基于风险的政策来批准变更，通过自动化方法推进低风险变更，只有高风险变更才需要人工批准。 所有重大变更必须在实施前由高级经理批准  第6部分 对于此页面上的问题，请思考你为测试生产系统的弹性所做的工作。\n1.以下哪些活动用于测试我们的IT系统/服务的弹性？\n 未在真实系统上进行沙盘推演 基础设施（包括数据中心）故障转移 应用程序故障转移 模拟破坏类生产的测试系统（包括故障注入、如降级网络链路、关闭路由器等） 模拟破坏生产系统（包括故障注入，如降级网络链路，关闭路由器等） 创建自动化和系统，定期，持续地破坏生产系统 其他。 请明确说明： 以上都不是  2. 你所在的组织多久执行一次中断生产系统的模拟（包括故障注入，例如降级网络链路、关闭路由器等）\n 从不 仅在初次部署 按周 按月 按年 少于一年一次 不知道或不适用  3. 你所在的组织多久执行一次基础设施（包括数据中心）故障转移以测试弹性？\n 从不 仅在初次部署 按周 按月 按年 少于一年一次 不知道或不适用  4. 你所在的组织多久执行一次应用程序故障转移以测试弹性？\n 从不 仅在初次部署 按周 按月 按年 少于一年一次 不知道或不适用  5. 如果我的组织在灾备演习时发现了任何改进的机会，我们会创建行动任务并在下一次演习前修复这些改进项。\n 非常同意 同意 有点同意 既不赞成也不反对 不太同意 不同意 强烈反对 不适用或我不知道  第七部分 此页将会询问您或您的组织关于云应用的一些问题\n1. 我主要负责的产品或服务在哪运行？（请选择所有适用的选项）\n  公有云（包含多个公有云）\n  私有云\n  混合云（将公有云和私有云/数据中心/本地设施结合在一起）\n  在数据中心或本地（不是云）\n  我桌面下的一个小服务器\n  其他 2.采用多个云提供商的驱动因素是什么？（请最多选择3个）\n  我们只有一个云提供商, 或者我们没有使用公有云\n  法律合规性\n  灾备可用性\n  对一个供应商缺乏信任\n  利用每个提供商的独特优势\n  谈判策略或采购要求\n  其他\n  3.请评价您对以下陈述同意或不同意的程度\n 我主要负责的产品或服务最初是设计在云中运行或基于云设计架构的。 对于我主要负责的产品或服务, 环境配置和部署仅使用存储在版本控制库中的脚本和信息, 无需手动步骤 (审批除外)。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n4.请评价您使用云服务时对以下陈述的同意或不同意程度。\n 一旦我有了访问权限, 我就可以根据需要独立地配置和配置产品或服务所需的云资源和功能, 而无需提高票证或需要人工交互。 我主要负责的服务或产品设计为通过网络从各种设备 (如智能手机、平板电脑、笔记本电脑) 访问, 而不需要专有插件或协议。 我的产品或服务所运行的云，服务于多个团队和应用程序, 并根据需要动态分配和重新分配计算和基础架构资源。 我可以根据需求动态地增加或减少可用于主要支持的服务或产品的云资源。 我可以监视或控制我主要支持的服务或产品所使用的云资源的数量和成本。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n5.换个主题，在您工作的时候，您是怎样看待成本的？\n 我的团队可以准确地估计操作我们软件的成本。 我的团队可以轻松识别我们运营成本最高的应用程序。 我的团队很少超出我们的成本费用或支出预算。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n第八部分 关于版本控制系统、分支模型、自动化测试、持续集成、持续交付等一直到生产环境的反馈等等实践。 现在让我们谈谈您和您的团队所做的技术工作。\n1.请介绍一下您和您的团队如何开发软件。我的团队：\n 我们的组织将所有代码存储在一个单一庞大的版本控制存储库中 组织中所有工程师都可以查看和搜索组织中所有代码 我可以在自己之外的项目中编辑代码，并适时提交 我们将应用程序的所有依赖项源代码（例如软件库）都存储到版本控制存储库中 我们为发行版本创建的所有包，包括依赖项，都是在单个版本控制中创建的，而不是从多个版本或分支中创建的  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n2.我们关注您工作中使用什么代码，请评价您对以下陈述同意或不同意程度\n 如果需要，我们很容易更改其他团队维护的代码 我很容易在代码库中找到示例 我经常从团队之外的工程师那里收到项目的更新。 我很容易重新使用别人的代码 我很容易对我的项目增加新的依赖项 我很容易移动新的依赖项版本 我的依赖项是稳定的很少破坏我的代码  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n3.我们关注您在工作中遵循的开发实践和模式。\n 我团队中的所有开发人员至少每天都会将代码推送到trunk / master 应用程序的代码库中不到三个活动分支 我们的应用程序团队从来没有代码锁定期，任何时候没有人可以签入代码或由于合并配置而执行请求。 在合并到master之前，分支和分叉的生命周期非常短（不到一天）。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n4.下一组问题是关于在工作中提交代码、搭建和部署软件。\n对于您使用的主要应用程序或服务：\n 代码提交会自动生成软件 代码提交会运行一系列自动化测试 每天成功地执行自动化的构建和测试 当构建中断时，它通常在十分钟内修复  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n5.许多团队使用自动化测试来优化他们的软件\n请评价您对以下陈述的同意或不同意程度 回答这些问题时，请考虑您自己的测试过程：\n 当自动化测试通过时，我确信软件是可发布的 自动测试失败可能表明存在真正的缺陷 开发人员很容易重现和修复验收失败的测试 我们测试必要的数据，以便每一步都能轻松运行自动化测试 我可以在十分钟内从自动测试中得到反馈 我们经常使用之前的测试运行数据来提高自动化测试套件的质量  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n6.请评价您对以下陈述的同意或不同意程度\n对于您使用的主要应用程序或服务：\n 我们的软件在整个生命周期中都处于可部署状态 我的团队优先考虑保持软件可部署而不是处理新功能 团队中的任何人都可以获得系统在质量和可部署性方面的快速反馈 当人们得到系统不可部署的反馈时（例如构建或测试失败），他们将优先解决这些问题 我们可以根据需要随时将我们的系统部署到生产或最终用户  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n7. 请结合自己的测试过程回答以下问题：\n 当通过自动化测试后，我相信软件是可发布的。 自动化测试失败表明存在真正的缺陷。 开发人员很容易重现并修复验收测试发现的缺陷。 我们有必要的测试数据，用于每个步骤中轻松地运行自动化测试。 我可以在10分钟内收到自动化测试反馈。 我们经常使用以前测试运行的数据来提高自动化测试套件的质量。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n8. 对于您工作的主要应用或服务：\n 我们的软件始终处于可部署的状态。 在我的团队中，保持软件处于可部署状态的优先级高于实现新需求。 任何团队成员都可以快速反馈系统的质量和可部署性。 团队成员将修复导致系统无法部署的问题（如编译失败、测试失败等）置于最高优先级。 我们可以随时根据需要将系统部署到生产环境或最终用户。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n9. 对于您工作的主要应用或服务，实现完全自动化部署到生产环境或最终用户的比例是：\n 0%-15% 16%-30% 31%-45% 46%-60% 61%-75% 76%-100% 我不知道或不适用  10. 对于您工作的主要应用或服务，部署过程需要多长时间才能使软件新版本可供用户使用：\n 小于1小时 在1小时和1天之间 在1天和3天之间 在3天和1周之间 在1周和1个月之间 大于1个月 我不知道或不适用  11. 您如何监控和了解正在运行的系统：\n 我的团队有一套技术解决方案用以报告系统的整体健康状况（如系统功能是否正常？系统是否有充足的可用资源等？）。 我的团队有一套技术解决方案用以报告基于用户使用情况的系统状态（如用户是否知道系统已关闭，是否有不良的体验等？）。 我的团队有一套技术解决方案用以监控主要业务和系统参数。 我的团队有工具用于协助我们了解和调试生产环境上的系统。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n第九部分 这页面询问了一些细节关于您的技术环境和工作\n请选择以下之一\n1. 为了部署我们的软件解决方案，我的团队使用以下CI / CD /测试自动化工具链\n 主要是内部开发（自研）的，且所有权属于我的组织 混合使用专有工具，开源和商业现成软件 主要是开源和商用现货，高度定制 主要是开源和商用现货，很少定制 主要是商业现成的套装软件 主要是开源的，高度定制 主要是开源的，很少定制 其他 不适用或我不知道  2. 请评价您对以下说法的同意或不同意程度\n 在我的团队中，与组织中的其他团队相比，我们的CI/CD/自动化测试过程和工具是为我们的需求而定制的  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n3. 请评价您对以下说法的同意或不同意程度。 通过CI / CD工具链部署软件时：\n 使用CI / CD工具链可以提高我的效率在我的工作中 使用CI / CD工具链在我的工作中提高我的生产力 使用Ci/CD工具链提高了我的工作效率 我发现CI / CD工具链在我的工作中很有用。  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n4. 请评价您对以下说法的同意或不同意程度。 通过CI / CD /测试自动化工具链部署软件时：\n 我的交互在工具链是清晰易懂的 与工具链交互并不需要我的大量精力 我发现工具链容易使用 我发现容易让工具链做我想要做的事  (强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)\n5. 选择最能代表谁负责创建和维护CI / CD /测试自动化工具链及其配置的选项：\n 我们的团队有完全自治选择和配置自己的CI / CD /自动化测试的工具链。 我们需要使用一个统一工具链，但是我们为构建/测试/部署过程维护自己的脚本，并且在配置方式上有很多自主权。 我们需要使用一个统一工具链具有预配置脚本和构建步骤，测试和部署过程的步骤，我们可以根据需要重构或自定义。 我们需要使用带有预配置脚本和步骤的统一工具链，而我们几乎没有能力重构它 所有构建，测试和部署软件，都由我们建立的统一团队处理 不适用或我不知道  6. 我的工具链包括以下内容（请选择所有适用的选项）\n 自动化构建 自动化单元测试 自动化验收测试 自动化性能测试 自动安全测试 自动化配置和部署到测试环境 自动化部署到生产 与chatbots / Slack集成 与生产监控和可视化工具集成 以上都不是  第十部分 最后一页！请花几分钟时间告诉我们你自己。 请注意，此数据仅用于研究目的，此调查是匿名的，仅以匿名方式汇总报告。\n1. 你的性别？\n 男 女 非二元 不想回应  2. 在您的团队中工作的女性比例是多少？\n请输入0到100之间的数字。  女性团队的百分比： [___] 不想回应  3. 您是否认定为少数派群体的成员？\n 是 没有 不想回应  4. 你认定是残疾人吗？\n包括与视觉，听觉，步行，记忆/集中，自我保健或沟通相关的残疾\n 是 没有 不想回应  5. 哪个最贴切地描述了你的工作角色？\n 开发或工程师 DevOps或SRE 信息安全 IT运营或基础设施 网络运营 产品管理 用户体验或软件分析 经理 专业服务 质量工程师或QA 发布工程师 销售工程师 销售或营销 我是顾问、教练或培训师 我是C级高管 我是学生 我不属于任何部门 其他 不想回答  6. 你有多少年的经验？\n 0-2 3-5 6-10 11-15 超过16 不想回应  7. ­­­­­请选择您所在的地理区域：\n 非洲 亚洲 中美洲 东欧洲 欧洲联盟 中东 北美 大洋洲 南美洲 加勒比  总结 本文是否帮你解答了这样一个疑问：每年的DevOps状态报告中的参考数据是从哪里来的？是通过什么方式采集的？到目前为止，我们还不清楚这些数据是通过什么打分规则和算法处理的。如果你是这方面的专家，请和我们分享以下你的观点。\n历年来的DevOps状态报告 如果你需要下载学习的话，请点击下面的链接（扫码二维码），这里还有历年来英文版报告全集和部分中文版本。\n","permalink":"https://devopschina.org/blog/2019-state-devops-survey-chinese-version/","tags":["问卷","调查"],"title":"中文版：2019年DevOps状态调查问卷"},{"categories":["AIOps"],"contents":"本文的英文原文是来自于SweetCode的《The Definitive Guide to AIOps》，这篇白皮书由CA公司赞助发布。社区组织翻译。\nAIOps是当前非常火热的一个话题，它和DevOps也有着紧密的关系。模仿Google关于SRE与DevOps关系的一个比喻，我们可以认为：AIOps是实现DevOps的一个类。\n 刘征、曾云龙、董沙莎、谢波、隋悦豪、朱宝、原驰、周一行； by 翻译团队成员 排名顺序为翻译工作章节分工顺序\n 可是AIOps到底是什么？不同的人有着不同的理解和定义。本文是一篇逻辑条理清晰，而且通俗易懂的文章。中国DevOps社区的AIOps翻译团队协作翻译了本文。\n本文的翻译发发布仅用了6天时间，如果发现质量欠佳的地方，请通过Github向我们反馈。Github地址：https://github.com/martinliu/aiops (英文原版也在此可以下载)请在Github上向我们提交pr或者issue。最近github也非常火，相信github的账号最近也很普及。言归正传，本github项目的目标是汇聚任何你也认为非常好的技术文章和网址资源。请大家与我们协作共创。\nAIOps权威指南：概述 在硬件和软件系统发展的更加高效、复杂和有效的同时，它们也在变得越来越复杂。例如，当虚拟机替代了裸机时，虚拟化给IT团队带来的是：新一层的必须规划以及管理的复杂度。近年来向微服务和容器转型的趋势，也同样导致了应用程序组件数量的激增，以及编排所有这些组件所带来的挑战。\n传统上，IT Ops团队的能力对于处理如此日益增加的复杂性会显得捉襟见肘。雇用更多员工成了最直接的对策，但这并不是一个成本效益较好的解决方案，也无法支持大规模的扩张。\n虽然，自动化工具对处理复杂性有一定帮助，但是传统的自动化工具依赖于人为配置、部署和管理，因此，自动化工具去简化日益复杂的IT环境的能力也是有限的。\n用AIOps应对复杂性 近年来，IT运营人工智能（AIOps）已成为了应对IT系统与日俱增的复杂性的很好的解决方案。 AIOps基于大数据、数据分析和机器学习来提供洞察力，并为现代基础设施和软件所需的管理任务提供更高水平的自动化（不依赖于人类操作员）。\n因此，AIOps具有巨大的价值。展望未来，AIOps将在IT团队提高效率方面发挥关键作用。它还会使应用复杂的下一代技术成为可能，而且那些技术是传统解决方案无法实现的。\n简而言之，失去AIOps的帮助，未来的企业将无法生存。如果您的企业尚未开始尝试基于AIOps的解决方案，那么现在就是评估、规划和实施它的时候了，AIOps工具应该对推动业务价值的交付大有裨益。\n本指南旨在为向AIOps迁移的人提供参考。它定义了AIOps，还分析了AIOps在当前IT行业里的现状。它还识别并解释了是哪些核心组件在驱动AIOps，以及以AIOps驱动的主要用例。\n第一章：AIOps是什么？ AIOps的定义 AIOps即利用机器学习、大数据和自动决策来完成IT任务。AIOps可以自动化那些需要人为进行大量手工干预的传统操作流程。AIOps是“基于算法的IT运营”或“基于人工智能的IT运营”的缩写，于2016年进入IT词典，当时是Gartner创造了这一术语，目的是探究怎样通过数据分析来为IT Ops团队带来新的效率提升。\nAIOps是创新么？ 数据分析和机器学习在企业中的应用已经普及了很多年了\u0026ndash;它并没有与AIOps一起出现。早在AIOps概念的出现之前，IT运营或IT Ops也作为一门独立的学科存在着。\n然而，AIOps的创新之处在于：它将基于数据驱动的洞察和IT运营结合在了一起。以前，数据分析主要是应用在提供业务洞察方面，而不是帮助IT运营团队完成工作。在某种程度上，数据和机器学习在IT Ops中发挥作用的情况，还主要局限于基础的安全和基础设施监控工具这些场景里。利用自动化工具能帮助IT Ops团队提高工作效率，但这些工具通常无法根据数据制定复杂的自动化决策，并且还要依赖更大量的人工配置才能使用。\nIT Ops团队使用AIOps来改变这种情况，AIOps可以通过收集和分析数据来制定更高级的决策，并且执行自动化操作的工具。它代表了一种将数据分析集成到IT Ops中的，更精细、更复杂的方法。此外，它还可以帮助传统IT运营管理员过渡到站点可靠性工程师（SRE）角色，并支持符合业务需求的可规模化的工作流。\nAIOps的现状 虽然没有关于当前AIOps采用率的精确数据，但是Gartner在2017年预测“全球25％的企业将在2019年战略性地实施AIOps平台来支持两个或多个主要IT运营职能”。此外，TechValidate最近研究发现97％的受访IT组织一致认为：实施具备可操作洞察力的AIOps解决方案有助于改善自动化，并增强整体IT运营部门的效能。\nAIOps已经被一些企业们提前采用了，只是大多数企业部署AIOps平台还需要一段的时间。\n目前阻碍AIOps应用的主要障碍包括：企业对AIOps的态度是否是真正的愿意迎接创新，又或仅仅是炒作而缺乏恒心。但这种怀疑可能会随着越来越多的企业采用AIOps而消失，因为AIOps的价值在变得更加清晰。在2018年NewVantage Partners调查中发现，有97.2％的高管正在投资建设或启动大数据和人工智能计划。\n企业在采集高质量数据方面的信心较低（再加上对如何更好地实施能够提供广泛、长期有价值的AIOps解决方案的不确定性）也阻碍了一些组织应用AIOps。然而，通过充分的研究和规划还是可以克服这些挑战的。\nAIOps的构成 想要有效的实施AIOps，首先要确定使AIOps成为可能的核心组件有哪些，并评估您的企业能有效实施这些组件的能力。\nAIOps的主要组成部分包括：\n 数据收集：收集数据是开始AIOps的第一步。成功的AIOps和大数据技术会使用不同的来源收集数据，根据需要转换和聚合数据，有效备份和保留数据，并持续有效的维护数据质量，为数据分析和机器学习提供动力。 数据分析：一旦数据被适当地收集和转换，就会执行统计分析，以便从数据中得出见解。 机器学习：机器学习是利用从数据分析中得到的见解来做出自动决策的过程。机器学习是通过算法实现的，这些算法允许软件自动对数据所表达的信息自动地做出反应。 人工智能（AI）：这里的AI指的是更广泛的自动化决策的范畴，机器学习是其中的一个组成部分。  我们下面将在讨论AIOps使用案例和实践的背景下探索每个组件。\nAIOps的用例 通过使用数据收集、数据分析和机器学习相结合的完整AIOps解决方案，IT Ops团队可以支持以下几个关键使用场景：\n 异常检测。也许AIOps最基本的使用案例就是检测数据中的异常，然后根据需要对它们做出反应。 原因分析。AIOps还可帮助IT Ops团队自动执行根本原因分析，从而快速解决问题。 预测。AIOps可以让工具能对未来进行自动预测，例如用户流量在特定的时间点可能会怎样的变化，然后做出相应的反应。 报警管理。AIOps在帮助IT Ops团队应对他们必须处理的大量警报，以支持正常的运营方面发挥着越来越重要的作用。 智能修复。AIOps通过自动化工具驱动闭环的故障修复，而不依赖于运维人员。  以下章节将会通过详细解释它们涉及的内容，以及取得了怎样成功效果方面，深入探讨这些用例。\n第二章：数据收集和规范化 数据是构成了AIOps的基础。因此，实施有效的数据收集和规范化的过程是创建AIOps赋能解决方案至关重要的第一步。\n数据收集是指将数据从数据源（通常具有多样性）移动到可以进行处理和分析的后台。\n数据规范化是为数据分析作准备的过程。规范化涉及将数据从一种格式转换为另一种格式，从而和数据分析工具保持兼容。经常还需要集成不同的数据集，以便可可以在一个统一的数据后天中进行高效的分析。\n为了高效地执行数据收集和规范化，组织应牢记以下挑战和最佳实践。\n数据源的异构和多样性 在大多数情况下，为AIOps平台提供支持的数据源，并不是都“诞生”在某个位置，或是某一种格式。这些数据来自于多种不同的格式，并分布在多个位置。\n例如，您的企业为AIOps收集的某些数据，可能来自以纯文本格式的Web服务器日志。同时，您可能还会从存储在压缩文件里的操作系统日志中收集其他数据，并且需要先解压缩后才能进行分析。从不同类型的数据库收集数据时会出现类似的挑战。例如，MySQL数据库中的数据通常与所谓NoSQL数据库中的数据格式不同。时间序列数据集也会对数据收集带来挑战，因为在进行分析之前，需要将不同时间收集的数据进行标准化处理。\n数据源和格式的多样性带来了两种不同的挑战：\n **组织必须能够从多个位置收集和汇聚数据。**执行此任务所需的工作量和复杂程度将取决于您拥有多少数据源，以及它们的分布范围。在大多数情况下，数据收集需要在各种系统上运行代理，这些代理可以收集它们生成的数据并将其发送到中央位置，然后进行后台存储和处理。 **通过将数据转换为与分析工具兼容的格式来规范化数据。**规范化不一定需要将所有数据转换为相同的数据格式。但是，通常至少需要执行一些数据集转换，以及利用Apache Hive，HBase和Elasticsearch等大数据工具提供的接口，将传统数据库中的数据与Hadoop等大数据分析工具进行集成。  实时数据操作 在规划和实施AIOps解决方案时，努力实现实时数据收集和规范化非常重要。实时数据操作意味着您可以在数据产生的同时快速收集和分析数据，从而获得实时的，接近于实时的洞察力。\n对于大多数AIOps用例，实时数据处理至关重要。如果您的目标是使用AIOps来探测哪些可能的安全漏洞异常，例如，一旦发生了违规行为，就立即能识别到，将比在攻击者已经开始利用您的数据和基础设施之后才发现问题，具有更大的业务价值。同样，当您使用AIOps进行软件或基础设施问题的根因分析时，您希望能够尽快找到问题的根源，以便在影响最终用户之前解决问题。在这两个用例中，在收集和规范话AIOps流程所需要的数据时，即使只有几分钟的延迟，也可能对实现业务业务目标的能力带来巨大影响。\n实现实时的数据收集和标准化就需要彻底的自动化这些流程。帮助您收集数据的代理和进行转换的工具，以及读取数据并进行分析的工具，必须都能够在没有人工辅助的情况下运行。否则，如果您将依靠管理员手动收集数据或执行数据转换，这就无法获得实时洞察的能力。\n数据保留和备份 尽管实时数据处理是AIOps的重要组成部分，但在AIOps过程完成后维持数据可用也很有价值。您可能出于合规性原因，需要保留一段时间的数据，即使不是这样，能够对数据进行回顾性分析也是有用的。\n这就是为什么您的AIOps计划应该包含对数据保留时间的评估，即您的业务对于收集和规范化后的数据，要求保留多长时间，以及如何备份数据以防止意外中断。虽然数据保留和备份策略根据业务需求而有很大差异，但决定最适合于您的组织的策略，通常要基于如下两个因素来分析：\n 恢复点目标或RPO RPO是您的企业可以承受的永久损失的数据量，而不会产生严重后果。如果您有高RPO需求，则必须常态化地、例行地备份数据。 恢复时间目标或RTO RTO是指您的企业在中断后可以等待数据再次可用的时间。高RTO要求需要配套备份流程，以能够快速恢复数据，还需要进行恢复时间的周期测试，以确保能够实现恢复目标。  为了降低数据存储和备份成本，企业可以利用公共云提供商提供的打折数据存储服务。这些服务通常被称为“冷存储”，提供低成本的数据存储，需要注意的是，数据访问通常会有一些延迟。对于不再用于AIOps的数据，这类延迟通常是可接受的。\n开放性 在为AIOps准备数据收集和规范化解决方案时，需要考虑的最后一个关键因素是基于闭源还是基于开源解决方案的问题。\n通常，选择开源解决方案比采用专有的闭源工具更好。后者可能导致锁定并限制您的企业未来修改AIOps工具集和流程的能力。\n因此，采用开源数据收集和规范化工具是最佳实践。开源工具包括：\n Apache Kafka Apache Hive Apache HBase CloverETL KETL Rsyslog Logstash Elasticsearch  请记住，许多专有数据收集和规范化工具都是基于开源解决方案构建的。一些此类平台比其他平台更“开放”并与第三方工具兼容。如果您考虑采用数据收集和规范化的商用工具，请评估其与第三方工具集成的适配程度，以避免被锁定而限制未来的拓展。同样，在考虑开源解决方案时，请务必评估关于配置和维护工具所需的工作量，是否于使用开源方案所节省的成本相匹配。\n第三章：检测 异常检测以定位问题并了解基础架构和应用程序中的趋势是AIOps的一个关键用例。检测可以让工具探测出异常行为（例如某个服务器响应速度比平时慢，或受黑客攻击而出现异常的网络行为）并作出相应的反馈。\n异常是什么？ 异常是相对于正常运行状态下的某个数据点或时间点所发生的情况。换句话说，它是个异常值。\n动态基线 虽然理解异常的概念很容易，但在很多情况下，在现代软件环境中进行异常检测，对于AIOps而言还是特别具有挑战性。因为在许多情况下，并没有通用的方法去制定合理的触发条件。例如对于在整个环境中的网络流量、内存和存储空间消耗而言，它们的波动还是会很大的。那么活跃用户量或应用程序实例也是如此。\n在这些情况下进行有效监测需要AIOps能采用足够智能的工具来设置动态基线。动态基线允许工具确认特定情况下（例如一天中的时段和应用程序的注册用户数）正常活动的范围，然后检测与动态基线不匹配的数据或事件。\n单变量与多变量异常 异常除了可以用动态基线探测外，AIOps检测用例需要考虑的另一个重要因素是单变量和多变量异常检测之间的差异。 单变量异常检测侧重于基于单个度量或数据点识别异常值。例如，当磁盘存储空间超过正常阈值时，单变量异常可能会生成报警。 相反，多变量异常基于一系列不同的变量来检测异常值。在基本的多变量检测方案中，采用了AIOps的工具可能同时分析磁盘使用情况、内存使用情况和网络流量，并评估整体行为是否出现异常。在这种情况下，个别的磁盘使用超量可能不会触发警报，但如果磁盘的高使用量与内存异常消耗和网络流量一致，则该工具可能会探测出存在异常的现象。这是一个简单的多变量检测示例。在更复杂的情况下，多变量检测方法依靠神经网络来模拟各种指标之间的交互，并根据它们交互的结果做出决策。\n因此，多变量异常检测可以提供更深入，更全面的理解能力。但是，多变量检测也是更难有效的应用，因为它需要确定出可以用于同时关联分析的多个度量指标，并建立能准确解释它们的算法。多变量检测的扩展也更难，因为随着引入更多标准变量，复杂性也会增加。 在大多数情况下，结合单变量和多变量检测方法的AIOps解决方案会提供最佳结果。单变量检测对于基本的报警和监控非常有用，而多变量方法可以为更复杂的自动化决策提供支持。\nAIOps解决方案的另一个关键功能是隐藏算法的复杂性。它应该根据被分析的数据类型自动选择正确的算法。\n检测模型的可扩展性 是指为AIOps提供驱动力的检测流程应该是可扩展的，面向未来的，而不是仅仅为满足于某一组有限的需求而设计地。\n可扩展检测策略的特征如下：\n 能够添加新指标，或修改检测模型中各种指标所提供的权重。 能够将新数据源和新技术添加到检测模型中。 支持持续适应的动态基线技术，因为行为变得更加细致和复杂。  这在实践中意味着检测模型开始通常很小，但随着时间的推移会增加规模和复杂性。首先，您的AIOps策略可能主要由单变量检测模型和一些基本的多变量方法驱动。他们可能会关注简单的指标，如内存和磁盘使用情况。但是，随着时间的推移，您可能希望通过引用当前热门技术所收集的指标来建立更复杂的多变量模型（例如容器的启动时间或无服务器功能的执行时间），这会使您的技术更加复杂。\n第四章: 因果分析 AIOps的另一个关键用例是因果分析。这指的是通过追踪导致一个问题的所有来源因素, 从而帮助解决问题本身的工作。\n因果分析的挑战 随着软件环境变得越来越复杂, 并且不同组件之间的依赖关系越来越难以在表面上进行关联, 因此，AIOps驱动的因果分析变得越来越重要。\n考虑以下场景, 例如有一个由前端组件以及后端数据库组成的 web 应用程序系统, 将该应用程序系统通过容器的方式，作为一组微服务进行部署。如果 IT 运营团队注意到 web 服务器已开始响应缓慢了, 这时若没有基于数据的自动化工具的帮助, 找出问题的根本原因可能会是相当困难的。这个问题有可能是由于网络瓶颈引起的。有可能是磁盘故障或数据库配置的问题导致的。又或许是容器编排器无法在多个容器实例之间正确地转发应用程序负载。甚至问题的根源有可能是应用程序代码本身。\n一个 IT 运营团队可以通过部署自动分析数据的 AIOps 工具, 来定位问题的可能原因, 而不是去手工的调查引发问题的每一种潜在的可能性。AIOps 工具可以通过分析网络连接模式、容器统计信息、应用程序分析器和数据库日志等信息, 快速地使问题可视化。AIOps 工具还提供端到端的可视化, 使 IT 运营团队能够找到他们自己或许从没意识到的问题。\n因果分析的数据采集与情景化 您的因果分析成效仅与您所收集到的数据等效。您还要决定应该执行哪些类型的因果分析, 然后确保您正在收集的、标准化的数据是正确无误的, 并且能够支持得了你要进行的分析。\n收集上下文信息和判断那些数据与您正在分析的问题是否相关也很重要。这包括了：过去类似问题所发生的频率和原因, 以及其他系统是否也遇到过类似的问题等。这样的上下文信息可以帮助您解释问题的范围和意义, 并对其进行合理的优先度排序处理。\n处理多种原因 有时, 导致问题的原因可能是多方面的。例如：在上面的 web 应用程序示例中, 网络带宽瓶颈和磁盘 I/O 问题都可能会导致应用程序的响应速度变慢。因此, 你的因果分析策略和结果，应该被设计成能够处理“必须要解决多种原因才能解决问题”的情况。\n原因也可以有多层。这里再次以Web应用程序举例，缓慢的响应时间可能是由于负载均衡的故障引起的，而负载均衡又是由于容器编排器缺少内存资源引起的。在这种情况下，解决了第一层原因（负载均衡器的问题）还不能解决根本问题。\n在这样的情况下，由于故障是多种原因导致的，图形建模有助于在解决问题时从各种表现原因中定位出根本原因。\n挖掘下钻 除了帮助您确定问题的原因之外，AIOps工具还应提供深度调查问题的能力，以便深入研究问题。例如，如果Web应用程序出现了故障，并且您确定原因是网络带宽的拥塞，您可能希望能够向下钻取，并确定到底是那种类型的网络流量（例如来自特定区域AZ的流量）与这个应用程序的瓶颈问题有关。\n诸如此类的洞察力还可以帮助您的IT Ops团队优化系统，使他们能够更好地应对问题的再次发生。通过这种方式，在AIOps的帮助下进行因果分析不仅有助于实时解决问题，还有助于通过防止问题再次发生，从而帮助IT Ops团队试试持续改进。\n第5章：预测和趋势识别 AIOps还可以帮助IT Ops团队预测未来的走向，并确定趋势，从而进行持续不断的改进。\n要了解预测和趋势识别的价值，请考虑以下用例。\n容量预测分析 对于大多数IT Ops团队来说，正确地调整基础架构是一个持续的挑战。如果组织不能给应用程序提供足够的计算、存储和其他资源，那么就会发生性能问题。另一方面，如果供给超量的的资源，则会导致低下的成本效率，组织需要因此而支付、配置和维护过剩的基础设施。\n通过帮助IT运营团队预测其随着时间的推移而增长的基础设施的需求，容量预测分析可以很好地应对这一挑战。他们甚至可以触发周期性的资源配额调整。例如：电商网站在每年的特定时段会遇到业务高峰，容量预测分析可以使电商网站在此时段扩容更多的IT资源，同时在其他时段实施缩容来节省成本。\n应用性能预警 除软件测试外，AIOps可以在应用程序部署之前发挥作用，帮助优化应用程序性能。例如，分析并预判应用程序对特定事件会做出怎样的响应。比如DDoS攻击产生了网络流量的突增，这时触发预警信息，IT运维团队可以更有效地为该类事件做好准备。\nIT运维团队效能 预测和趋势识别可以帮助IT运维团队提升自身的能力。例如：在某个时间窗口内如何响应事件？哪类问题导致了最多的事件？通过分析数据来识别趋势，AIOps可以回答这些问题，以便IT运维团队知道在哪里投入更多资源。\n第六章：智能修复与自动化 AIOps不仅可以帮助IT运维团队识别问题和故障定位，还可以加快故障的修复过程。\n快速修复场景 快速修复场景的重要性很容易理解。在日常业务运营中，超过半数的用户会放弃一个加载时间超过3秒的网站，并且页面加载时间延迟1秒，就会导致销售额减少7％。业务部门无法接受由于网站可用性或性能导致的问题，需要快速进行修复。在实时采集和分析的数据的同时，采用AIOps可以迅速深入问题，帮助IT运维团队跟踪问题的原因并提供建议补救措施，以便尽快恢复业务。\n利用历史数据进行修复 AIOps还可以帮助IT运维团队解释与过去问题相关的历史数据，以便在发生类似事件时建议解决方案，从而加快事件解决速度。在没有AIOps的情况下，通过大量日志和其他数据进行解析以识别两个事件之间的相似性，并确定对第一个事件起作用的解决方案是否也可以有效地解决第二个事件，这种方式是不可行的。然而，支持AIOps的解决方案可以基于历史数据提供快速洞察，以帮助应对这一挑战。\n自动化恢复方案 AIOps工具甚至可以在识别问题后采取自动操作来解决问题。例如，他们可以自动阻止一台主机或关闭端口来阻止安全威胁，或者如果确定现有实例不足以满足需求，则可以启动应用程序的其他实例。\n自动化恢复方案实际并不是在所有情况下都实用；有时，事件的最终恢复方案不得不手动实施，即使AIOps可以提供有助于定位恢复方案的参考依据。然而，随着机器学习算法变得越来越复杂，AIOps工具可以自动解决的问题将会增加，从而实现更快，更无缝的事件恢复方案。\n第七章：压制噪音-管理告警 虽然AIOps能够比IT运维团队使用手动工具实现基础架构和软件更广泛，更快速的可视化，但也会产生信息过载的风险。如果AIOps工具部署或管理不当，它们会生成非常多的告警，以至于IT运维工程师会不堪重负并开始忽略通知。这个问题，通常被称为告警疲劳，将会降低基于AIOps的监控和分析的价值。\n避免告警疲劳并成功管理告警需要以下几种最佳实践：\n 避免手工告警阈值。 基于固定阈值而手动配置的触发告警在当今的动态环境中是不起作用的。手动配置告警不仅需要相当长的时间，而且还会导致误报，因为在某个时刻可接受的磁盘，网络或其他资源消耗可能会在下一时刻与环境一起发生变化。为了替代人工配置告警阈值，AIOps工具可以自动设置阈值。它们还可以利用动态基线（如上所述）来配置告警何时触发。 可操作的告警。 告警应该附带有助于IT运维团队响应问题的信息，而不仅仅是表明问题已经发生。也就是说提供上下文信息将会帮助工程师更彻底地了解问题。可操作的告警还可以包括基于数据的恢复方案的建议，供工程师考虑。 避免冗余告警。 通常情况下单个根本原因的问题会触发多个告警。例如，数据库故障可能会影响多个应用程序并导致每个应用程序发出告警。在这种场景下，多个告警会分散IT运维团队的注意力，而不是帮助它快速解决事件。AIOps工具不应生成冗余告警，而应智能地将多个问题映射、聚焦到单个根本原因，并生成一个告警，以帮助工程师快速解决该问题。  第八章：AIOps和数据分析的未来 除了提高企业对AIOps解决方案的采用率之外，AIOps的未来还有哪些内容？以下趋势可能会成为AIOps领域的重要组成部分，因为它将在未来几年继续发展。\n支持日益动态的环境 如上所述，AIOps的部分吸引力在于，它使IT运维团队能够更有效地处理高度动态的基础架构和软件环境，例如物联网设备，容器和无服务平台。\n展望未来，可能会出现更新的技术，为IT运维团队必须支持的部署模型引入更多活力。虽然这些技术的确切性还有待观察，但可以肯定的是，AIOps将成为管理它们的关键推动因素。\n识别图形模式 我们已经在上面指出了图形建模如何帮助理解特别复杂的因果关系。\n虽然一些AIOps工具已经在一定程度上利用了图形模式识别，但预计图形建模的作用在未来会越来越重要。随着AIOps工具处理的数据量和复杂性的增长，图形模型将有助于它们提供更高层次的洞察力。\n遗传算法 随着AIOps的发展，在AIOps应用程序中，遗传算法的使用可能会显着增加。遗传算法是指通过使用数据和机器学习，自动优化自身来改进的软件逻辑。例如，当AIOps算法反复处理某种类型的问题时，它将自动学习哪些解决方案最有效，并训练自己在未来做到那些。\n遗传算法是AIOps工具实现持续改进能力的重要组成部分。它们不仅可以通过IT Ops工程师减少手动工作来更快地解决问题，而且还可以使AIOps工具本身随着时间的推移变得更快，更准确和更有效，而无需手动更新。\nCA的AIOps解决方案 自几年前推出以来，CA Technologies一直处于AIOps生态系统的最前沿，并将随着AIOps的发展继续保持领先地位。\nAIOps功能由CA通过其Digital Experience Insights平台提供，并且包含CA的APM和API监控解决方案的基本部分功能。 CA最近还推出了数字运营智能，这是一种支持AIOps的解决方案，可提供跨域上下文智能，帮助IT运营团队制定更明智，更快的决策，以增强用户体验并提高IT服务质量和性能。它基于开放，功能强大的引擎，通过摄取和分析各种数据集（包括指标，拓扑，文本和日志数据），为用户提供全面的见解。机器学习驱动的分析，以及开箱即用的可视化和关联性，有助于提供卓越的用户体验并提供显著的运营效率。\n详细了解CA如何在您的AIOps之旅中为您提供指导。\n关于CA Technologies CA Technologies帮助客户在未来成功，未来从服装到能源的每种商业都在被软件改写。‌从计划到开发到管理到安全，CA公司建立的软件，可以为应用经济中的企业提供转型的燃料。在他们的IT战略的中心使用CA公司的软件，组织能够使用改变我们生活方式的技术，从数据中心到移动设备。‌我们的软件和解决方案帮助我们的客户在新的应用经济中茁壮成长，我们交付部署监控和保证他们的应用和基础设施安全的方法。\n关于Sweetcode.io Sweetcode.io是由Fixate IO所有和管理的网站。‌它的目标很简单：给技术人员一个共享他们的知识和用高价值的从业者制作的技术内容影响市场的地方Sweetcode承诺发布巧妙设计的内容，支持成熟的开发人员的成长，同时为刚刚开始他们的事业的人作为平台提供服务。‌网站上的所有的内容是从业者制作的，Sweetcode致力于从不知名的开发者获取内容，以给他们一个共享他们的知识的地方。\n","permalink":"https://devopschina.org/blog/aipos-definitive-guide/","tags":["DevOps","AI"],"title":"AIOps权威指南"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/project/art-institute.1/","tags":null,"title":"Art Institute of Chicago"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/project/art-institute/","tags":null,"title":"Art Institute of Chicago"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/service/business-consulting.1/","tags":null,"title":"Business Consulting"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/service/business-consulting/","tags":null,"title":"Business Consulting"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/project/carpe-diem/","tags":null,"title":"Carpe Diem Santorini"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/project/celebrate-with/","tags":null,"title":"Celebrate with Stoli"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/project/essential-looks.1/","tags":null,"title":"Essential Looks Trend Report"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/project/essential-looks/","tags":null,"title":"Essential Looks Trend Report"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/service/invesment-planning.1/","tags":null,"title":"Invesment Planning"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/service/invesment-planning/","tags":null,"title":"Invesment Planning"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/service/market-analysis.1/","tags":null,"title":"Market Analysis"},{"categories":null,"contents":"Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.\nQuia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\nBenifits of service Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n Quality Services Clients Satisfaction Quality Services Clients Satisfaction Quality Services Clients Satisfaction  Business Strategy Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia dese runt mollit anim id est laborum. sed ut perspiciatis unde omnis iste natus error sit voluptatem acusantium.\n Quality Services Clients Satisfaction Quality Services  Analyze your business Quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam.\n","permalink":"https://devopschina.org/service/market-analysis/","tags":null,"title":"Market Analysis"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/liuzheng/","tags":null,"title":"刘征"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/lyq/","tags":null,"title":"刘扬清"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/yd/","tags":null,"title":"姚冬"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/zn/","tags":null,"title":"张楠"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/lwg/","tags":null,"title":"李伟光"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/yr/","tags":null,"title":"杨瑞"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/lwd/","tags":null,"title":"林伟丹"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/wl/","tags":null,"title":"王磊"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/wlj/","tags":null,"title":"王立杰"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/why/","tags":null,"title":"王红阳"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/wyw/","tags":null,"title":"王英伟"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/sj/","tags":null,"title":"苏靖"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/mona/","tags":null,"title":"覃佳欢 Mona"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/zwy/","tags":null,"title":"赵文毅"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/cwf/","tags":null,"title":"陈文峰"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/cl/","tags":null,"title":"陈玲"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/cq/","tags":null,"title":"陈茜"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/gjn/","tags":null,"title":"高俊宁"},{"categories":null,"contents":"","permalink":"https://devopschina.org/team/hj/","tags":null,"title":"黄隽"}]