“DevOps的价值是又快又好地交付软件”——《凤凰项目》的作者Gene Kim和《持续交付》的作者JezHumble当前数字化转型的形势下，软件行业面临着巨大的市场机遇，而软件系统复杂度不断增加，跨地域高效协作、多环境部署等问题也逐渐突出，DevOps能帮助企业提升软件研发效率，通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加快捷、频繁和可靠。基于此，我们策划组织了2期【DevOps职业认证训练营】，并邀请到姚冬、卜汉东两位专家老师全程陪伴学习与答疑。在整理问答的过程中我们发现，学员提出的问题覆盖了规划设计、开发集成、测试、部署发布、运维监控等DevOps落地实践中的关键疑点与难点。本文从中挑选整理了60个精华问答，希望通过这些问题与解析，帮助更多DevOps实践者解决DevOps落地过程中的疑惑与痛点。（文末可下载大纲模式的pdf文档方便浏览）【一、华为端到端DevOps概览】Q1：华为端到端的DevOps工具链是如何承载敏捷和DevOps相关理念和方法的？A：敏捷和DevOps的理念其实是相通的，DevOps可以视作敏捷的延伸，敏捷思想打破了需求与开发之间的壁垒，DevOps则通过将开发与运维间的壁垒打破，打通软件交付全流程。华为云DevOps工具链DevCloud包含了从需求管理到代码托管、构建部署、测试等一系列步骤，覆盖软件开发全生命周期。理念往往需要结合实践，我们可以通过DevCloud进行需求管理、每日站会等等许多敏捷实践，通过提交代码可以触发执行流水线，让开发人员专注开发。Q2：华为云DevCloud与传统基于开源组件拼接的工具链，有什么差异优势？A：传统的由开源组件拼接而成的工具链，大部分都是使用Jira来进行需求管理、用Git来做代码托管、用Jenkins做DevOps开发，因为其组件大部分都是开源的，所以一般费用较低或者免费，其缺点是使用者需要掌握很多工具，而且这些工具并不是在同一个平台上。华为云DevCloud是一站式的软件开发平台，可以做到所有工具都在一个平台上，端到端打通覆盖整个软件开发全生命周期。用Jenkins的人都知道，在使用之前首先需要搭建一套Jenkins的环境，还需要定制化地做一些脚本、配置等，华为云DevCloud相当于是一个已经封装好了的DevOps开发工具，可以极大减少这些操作。在华为云DevCloud里，将编译构建、部署任务等做成了原子化的操作，如果我们想要做Tomcat部署，可以直接使用这些模板，只需要对里面的步骤进行细微的调整即可。而且它还使用了可视化视图，操作起来一目了然，学习成本也比较低。华为云DevCloud还支持代码检查、自定义shell、Python、脚本、自定义report展示。Q3：DevOps /敏捷和SDLC 有何不同？A：DevOps/敏捷和SDLC的角度不一样。SDLC是指系统生命周期，它提出的几种典型生命周期模型包括瀑布模型、快速原型模型、迭代模型。敏捷打破了需求和开发之间的沟通壁垒，DevOps则打通了整个软件交付的全流程。Q4：DevOps人员在与项目的结合中是否会承担更多开发、测试、运维的工作？A：DevOps不会让人去承担更多开发、测试、运维的工作。DevOps里有一个理念：让开发的人专注于开发、测试的人专注于测试、运维的人专注于运维，所有的工具层面的东西全部交给工具，只要把一切可自动化的东西自动化，所有的人忙自己手头的工作就好了。Q5：DevOps的反模式有哪些？A：参考《9种DevOps团队结构适用类型与7种反型》 Q6：DevOps适合哪些行业的业务模式？对于非软件行业是否需要调整模式?A：DevOps也好，敏捷也好，其初衷和理念适用于所有行业，但是每个行业在执行和实际落地效果上会有一些折扣，比如持续交付的生产环境、自动化部署、质量管控、自动化流转等过程的实现等。简单而言，互联网的一些应用，或者说SaaS应用，相对来说更适合DevOps的研发模式。原因是：其业务对软件更新、发布的要求较高；没有太大的历史包袱；相对更容易对标目标受众群体，包括生产环境等。传统类的业务比较重，比如银行的核心系统，实践起来相对较难，也不是说不能用敏捷或DevOps。比如持续集成、每天多次构建、多次提交代码、自动化测试、可视化等，都可以实行。对于非软件行业，如硬件、嵌入式、机械类，实践起来也比较难，比如测试自动化等，需要做一些工具或平台的适配，引进插件或工具后，流程也能够跑起来，只是会慢一些。综上，我认为敏捷和DevOps本身是一条没有终点的路，所有行业都可以到这条路上来，只是走得难易与远近的问题。Q7：在企业落地DevOps有没有什么套路？A：企业实际情况各不相同，落地DevOps没有统一的套路，但会有一些建议的方式。DevOps偏工程侧，通常建议先把版本管理建立起来，比如Git代码仓、代码分支管理等；接下来需要把流水线构建起来，在上面逐渐进行自动化测试、分层测试等。Q8：最能有效促进Scrum团队本身的持续改进的是什么实践？A：每个团队遇到的问题都是不一样的，如果一定要找一个通用的答案，首先要保证团队每日站会、评审会议等如质如期进行，以此来保持持续改进。 【二、持续规划与设计】Q9：基于DevOps实现持续有效规划应该先从哪个层面去入手呢？A：首先需要理解DevOps和敏捷的含义，我们一般说的规划与设计更偏向于敏捷项目管理中涵盖的需求和计划。狭义的DevOps主要是CI/CD，即持续集成和持续部署，是偏工程侧的。广义的DevOps，即本训练营中讲的DevOps是“端到端的DevOps”，从持续集成/持续部署，向前延伸到业务侧，向后延伸到运维/运营侧，因此也涵盖了前段的需求和设计层面。回到问题，基于DevOps实现持续有效规划，应该从需求和计划切入，包括整个的市场分析、目标客户群体的用户画像，用户的痛点是什么，针对这些痛点提供什么样的功能，然后到产品应该怎么设计，接下来才真正落到研发这个主体上。从方法论角度来看，需求和设计层面的方法论包括设计思维、精益创业等。做好需求分析后，就要进行需求拆分，排列优先级，这样就进到敏捷项目计划里，方法论包括看板、Scrum等，大规模团队敏捷框架有SAFe等。Q10：Scrum，看板和 XP 是敏捷开发的具体方式，老师能否具体讲解一下区别？A：参考文章《DevOps VS 敏捷：傻傻分不清楚》。Scrum和看板更侧重在团队级敏捷项目管理层面，XP更偏向于工程实践层面。Scrum和看板两者比较：“标准的”Scrum包括3355的框架；看板源自丰田的精益生产，其背后是精益的思想，通过可视化、限制在制品的数量，快速暴露问题和瓶颈点，集中对最严重的瓶颈点进行修复，然后去寻找下一个瓶颈点。DevOps的很多理念同样借鉴了精益的思想，个人认为，看板可以应用到很多领域。另外，Scrum和看板在实施或应用时并没有冲突，可以结合起来使用。 Q11：企业组织架构中什么角色或者部分适合推行DevOps落地？A：企业组织架构中一般都没有专门的组织来推行和落地DevOps。DevOps包括两个部分“Dev”和“Ops”，就是指开发部门和运维部门。几种常见的情况：如果是由开发部门来发起DevOps落地，就是由开发往运维去推进。我们平时看到比较多的是测试团队或传统的质量管理部门来发起，从开发到测试再往前一步到运维生产环境上去，因为这些部门本身就承担着代码托管、编译构建、自动化测试等职能。而有的公司会把内部的基础设施、IT支撑、测试等放在数据中心，往前去推把自己变成类似我们讲的DevOps工程师，然后通过自动化工具帮助开发团队进行自动化部署等，这就是从运维侧往前推进DevOps落地。还有一种情况，就是近年来比较火的云原生，架构师更多考虑采用微服务架构，通过基础设施即代码等方式自动化部署到Docker环境中去，因此引入自动化流水线、Infrastructure as Code（基础设施即代码）、接口测试等实践，这些都属于DevOps的范畴。还有一些其他的角色，比如敏捷教练、内部的技术教练等，他们本身就是在做研发管理的落地实践，很自然地转化去做DevOps推进。综上，DevOps的推进和落地不一定非要有一个DevOps工程师或独立的DevOps团队，初期引入DevOps的时候需要有一个团队或角色去承担起这个职责，进行概念和实践的导入和探索，这时更容易把DevOps工程师、DevOps团队建立起来。而后期应该把这些工程师或能力分散到各个团队中去，让DevOps在企业内有更广泛的传播和实践。Q12：请问在Scrum中，如果没有项目经理，是由TeamLeader还是ScrumMaster协调资源？A：应该由TeamLeader来协调资源，ScrumMaster不是管理角色，而更多的是一个辅助的牧羊犬的角色，在Scrum实施过程中守护团队Scrum流程不受干扰。Q13：对于非产品形态的项目，Product Owner来自哪个部门更合适？（业务部门/研发部门）A：Product Owner代表客户，一般是哪个部门更接近业务，更了解业务和系统，就由这个部门的人来担任。非产品形态项目的Product Owner，要求既了解业务又懂技术，一般可以由业务分析师、PMO等角色担任。Q14：实际开发中，客户往往无人承担PO的角色，而是领导来承担，如何破解这个问题？A：这种情况可称为“BDD”，Boss-Driven Development，老板驱动开发。好处是至少有一个人能拍板；坏处是拍板的人，你可能很难去辩驳或谈判，所以最好还是能够把客户侧的人拉进来。当然，如果老板确实对业务非常了解，也非常专业，并且是一个可沟通的人，也是可以的。PO的核心要求是需要有一个人代表客户或业务侧，针对需求或范围做决定，且当团队有问题的时候，可以随时找到这个人。Q15：影响地图主要应用于哪个环节？A：从HE2E DevOps实施框架图可以看到，在端到端的DevOps实践中，影响地图通常用于需求规划或业务规划阶段，与传统的Scrum流程相比，更偏业务侧。影响地图通过四层结构：why、who、how、what来拆解业务和需求，也可以用于运营或项目冷启动环节。Q16：请问如果一个大的Story拆分成多个小的Story，甚至再次拆分成孙子辈的Story，如何更好地表示这些关联关系？A：Story拆分有两种方式：一种是从epic（史诗故事）到feature到story的拆分，epic以月为单位，feature以周为单位，story以天为单位；另一种是平级拆分，所有拆分的故事全部叫story，只不过它们之间存在父子关系。不管是三层还是四层，我们只关注父子关系，从一个父story拆分出子story，如果粒度不够小，则以子story为父story继续拆分出它的子story。如果系统需要有层级追溯，可以用树状或脑图等结构来展现。Q17：学完课程感觉用户故事和项目管理里的工作包很像，二者有个共同的问题，拆解到什么粒度是好的用户故事？A：故事也好，需求也好，只是一个名字，用户故事之所以叫用户故事，有两点表征：1）它是站在用户的角度去看；2）它讲了一个故事、一个场景。好的用户故事遵循INVEST原则，即一个合适的用户故事应该是独立的（Independent）、有价值的（Valuable）、可讨论的（Negotiable）、小的（Small）、可估算的（Estimable）和可测试验证的（Testable）。Q18：如果采用敏捷开发，最终的用户需求如何呈现给用户？如果是需要存档的用户需求说明书、设计说明书或操作手册之类的文档，适合从DevCloud导出后再修改么？另外如果出现变更，如何确保文档与代码一致？A：如果是需求文档，可以以用户故事的形式存放，华为云DevCloud或者其他工具都提供多元的存储格式，如文本、图片、附件等，华为云DevCloud有一个帮助网站，每一个新上线的功能都会在这里进行同步和更新。也可以把词条或需求存放到wiki里，并跟前端的需求条目之间建立链接。wiki本身是可以有层级关系的，可以把需求从wiki里导出来形成文档形式，如果做得好，还会有版本计划，比如版本里包括10条需求，可以统一导出一篇需求规格说明文档。需求和代码之间的同步，可以通过流程等方式去控制，比如发版的检查点，这可能需要以人工方式去做，但也可以通过一些工具来辅助。比如提交代码的时候需要提交注释，可以把这个注释关联到一个工作项上，一个需求可能会修改多个文件里的多段代码，这其实就是一个完整的变更集的概念，这个变更是为了同一个目的，是有相关性的，如果要从代码里去剥离的话，应该会把这一次变更集统一进行剥离。在未来查看代码时，可以进行代码版本比较，看两个版本之间进行了哪些增加/修改、这些变更是为什么目的、其意图是什么。Q19：对于变化的需求或者新增的需求，是应该放到当前迭代里，还是规划到后面的迭代里，持续规划是指规划过程贯穿整个生命周期么？A：变化或新增的需求都会统一放到一个大的池子里，我们称之为product backlog（产品待办事项列表），这是一个一维的表格，所有需求按照优先级排列。我们要通过判断新进需求的优先级，看它应该放在什么位置。敏捷强调需求是动态变化的，我们会定期对需求列表进行梳理，看是否需要进行优先级排序的调整，因此变化或新增的需求不会放到当前的迭代里，因为当前迭代是一个固定的时间窗口，且范围相对固定，团队对此进行了承诺。我们会将其放入大的需求池，是在下个迭代还是之后的迭代实现，取决于该需求的优先级。Q20：对于初学者刚刚接触一个项目，但是项目的需求不明确、结构不成熟，怎么从敏捷入手？A：这里包括两种情况：初学者、项目在初级阶段。如果是初学者，应该通过获取现有资产快速熟悉和上手；如果项目处于初级阶段，需求也不太明确，可以通过敏捷的快速交付、精益的MVP等实践，快速获取反馈，对后续工作进行指导和建议。Q21：作为整个项目的入口，需求的质量如何把控和评测？A：明确定义需求可以转开发的标准，即DoR。那什么是DoR呢？敏捷开发发展了几个年头之后，人们发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代的失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，就是Definition of Ready，简略称之为“DoR”， 最初的Ready是指准备好可以进入迭代开发。Q22：持续规划与设计有什么度量数据或指标用于衡量团队绩效或用于持续改进？如何衡量持续规划与设计的成熟度？A：度量工具推荐Scum的燃尽图、看板的累积流图。研发效能的核心度量数据指标包括团队速率、Lead time，即需求的平均交付时长。Q23：敏捷下的组织过程资产（配置、文档等）这些有好的存储方案么？A：理论上文档、资产等都存储在资产库里，常用的知识库或资产平台有Conflunce、IBM的Rational Asset Manager等。资产和知识是不同的概念，现在做资产管理的相对少一些，知识库可以用wiki等平台，便于统一维护更新和协同。Q24：DevOps 持续规划与设计在DevOps生命周期中是处于开始的时刻，为什么还说代码集成是整个DevOps生命周期的核心呢?A：“代码集成”包括两部分：代码和集成。整个软件生命周期包括三个版本：需求版本，即发版计划；代码版本；上线发布的二进制包的版本。其中代码版本处于承前启后的中间位置，且是唯一真正有价值的。需求和文档是没有价值的，只有由代码编译成二进制包并部署上线才是有价值的。在代码层面多花一些精力是非常有必要的，所有的研发其实都是在一个代码仓库里进行协同开发，包括代码版本管理、分支管理等模式，因此将代码视为DevOps生命周期的核心也是必然的。软件研发最痛苦的地方往往是在集成层面，一开始大家各写各的代码，一旦要将这些不同的代码进行集成的时候，问题就出现了。持续集成的概念来源于XP，“如果代码集成是一件非常痛苦的事情，那我们就每天多次地进行。”一切杀不死你的都会让你更强大，持续地进行集成，你会想办法去减少集成的痛苦。就像跑步一样，假如以前的集成是一块大石头，每天多次集成就相当于将这块石头变成一颗颗的小石子，大石头打在身上会非常疼，小石子就好多了。这也是我们为什么要把集成往前提，并且持续去进行的原因，所以在DevOps生命周期中持续集成也非常重要。【三、持续开发与集成】Q25：如何加强开发人员对于版本质量的信心？A：加强对版本质量的信心，不只是针对开发人员，对所有人都应该如此。整个DevOps的过程其实就是在保障整体的版本质量，包括静态代码检测、接口API测试等。另一方面，版本对需求的映射关系或完成程度，应该从业务场景往下去切，看整个需求的匹配程度。第三点应该是我们通常说的非功能性需求（Non-functional requirements），比如负载、性能、安全、并发支持等，这些要根据我们服务承诺的质量来做相关措施。 Q26：敏捷开发相比传统开发有什么优点？A：我认为最大的优点或特点是敏捷开发更真实，或者说它更愿意承认研发的本质或现状。传统的研发认为质量受三个因素制约：范围、资源、时间，且默认范围和资源投入是相对确定的，时间是变化的。然而，在真实场景或变化的市场下，时间和资源是固定的，没办法讨价还价，因为市场、业务、客户都不会等你，在这样的前提下，软件的需求或范围实际上是可以商量或讨论的，我们要以可变的范围去赢得市场、时间窗口。敏捷开发要求我们不断交付高优先级的需求，并获取反馈，不断调整。这是敏捷开发的最大的核心，承认市场是变化莫测的，需求范围是可变的。Q27：一个产品，既有主线版本，又有很多的行业定制分支（50+），适合什么样的分支策略？A：这种场景在传统的产品里比较常见，个人认为应该考虑的是产品策略而不是分支策略。如果分支非常多，会导致产品碎片化严重。我们在持续集成、持续交付的时候，推崇主干开发或短的分支，不希望这些分支长期存在，否则在产品进行合并时会非常痛苦，工作量也会随着分支的多少和分支存在的时间呈几何倍数增长，所以不建议用长期存在的分支。那可以用什么样的方式来解决呢？首先要看整个版本上是否一定要出现这么多定制化的分支，这些分支有没有可能通过配置文件、功能开放等方式处理或实现。举个例子，我们做项目管理的软件，每个客户要求的字段、功能流转的流程都不太一样，如果都通过代码实现，有多少客户就会出现多少个分支，可能都不止50个。我们是怎么做的呢？针对字段，我可以配置一个界面，里面包括常见属性的字段，这个字段可以是文本类型或下拉框等形式；功能流转的话，新进来一个需求，它的下一个状态是什么、应该触发什么动作、应该是什么样的角色来触发这个动作等这些都是可以进行配置的，这些配置信息存在数据库里，变成用户的配置数据，这样我的主代码主程序是保持不变的，只需要提供一套模型根据数据去驱动适配或实现。这是我们更推崇的方式，可以用来消灭那些分支。Q28：日常项目开发，在代码分支管理上经常疑惑用什么分支管理策略，比如是选择基于生产分支工作流，还是基于环境等等，在实际实践中，我们应该重点考虑哪些因素？既可以兼顾管理效率，又可以确保代码质量。A：个人建议采用分支开发主干发布或分支开发分支发布的分支管理策略。基于环境进行分支构建的话，以前我们会有开发库测试库等仓库管理的概念，但现在全部是持续集成、自动化部署，就没必要再基于环境去拉取分支了。如何保证代码质量，我们在CI/CD流水线、自动化部署和构建的同时需要考虑每一个环境上跑哪些测试，这些测试大部分通过自动化的方式实现，也有少量的是手工进行。Q29：像华为云这样团队成员能力超强、应用场景以线上服务为主，一般会采用什么样的分支管理模式？A：华为云团队也是采用特性分支的管理模式，同时会做多级流水线触发不同环境的流水线来做相关构建，除了开发环境的流水线以外，还有测试、类生产环境等流水线。Q30: 要做到主干上的提交始终处于可发布状态，不受隐含的代码冲突、提交的feature只部分完成等因素影响，对开发团队和基础设施有哪些要求？A：首先主干上提交的流程或质量要严格控制，真正达到DoD（Definition of Done）的标准，这里可能需要一些机制人为地进行管控，比如Committer机制等。提交的时候，除了非功能性的要求，比如跑相关的回归测试、代码检视以外，还有很重要的功能性要求，比如对需求的实现程度的检查。另外“基础设施即代码”，还要看持续集成、持续部署、自动化测试能不能快速有效地跑起来，并保持高度一致。Q31：持续集成的成功因素是什么？ A：持续集成主要包括代码仓库、自动构建、自动部署、自动测试四个方面。要求每人每天都要向主干提交代码，触发自动构建和自动部署，在类生产环境进行自动化测试，同时需要团队每个成员确保清楚正在发生的状况，以此来保证持续集成的成功。Q32：华为云上的CI/CD与K8s上搭的CI/CD有什么区别？A：华为云DevCloud打通了端到端的软件交付全流程，集成了常用的DevOps开发工具，不仅可以完成CI/CD，还可以直接在上面进行项目管理和开发；而K8s只是软件开发中一个单独的工具，没有项目需求管理等功能，需要配合其他工具一起使用才能实现完整的软件开发与交付。Q33：开发和修复bug的工时如何进行安排呢？之前迭代出来的bug是按照单独工时安排，还是统一安排在开发中？A：主要看发版的标准和要求是什么，通常来说可以带病发版，但如果是非常严重的缺陷，就不能上线，必须先修复这些bug。一般bug会跟需求放在同一个池子里，根据它的优先级和影响程度来进行排序，决定是先修复bug还是先做需求。如果修改bug是为了扫清技术债务，建议在一个迭代里固定一定比例的时间来进行。Q34：感觉SaltStack和Ansible中哪个是最好的配置管理（CM）工具？为什么？A：两者定位不一样。个人认为Ansible并不是一个标准的配置管理工具，它更多是通过自动化部署的手段去touch环境这一侧，SaltStack相对来说功能性更强一些。Q35：在代码互评审和评审流程中如何高效的提升代码质量？A：人机结合，将重复性的，比如检查代码风格、命名规则等工作交给工具；人工集中看代码实践的逻辑、对需求的匹配等。将人从重复性的工作中解放出来，节约时间和人力。华为实行代码审查Committer机制，开发人员提交代码后，会自动拉起自动化代码检查。提交一个Pull Request，工具匹配相关的review进行评审和打分，如果是重要实现还可能会有一个评审会议，然后进入最终Committer决定是否将提交的代码合并到主干上去。【四、持续测试与反馈】Q36：“通过持续测试实现快速与高质量“是敏捷测试原则之一，而测试金字塔顶端的一些测试往往依赖许多外部因素，较为脆弱，容易因被测软件之外的因素而失败；且由于这类测试同时测试了软件中的多个模块，定位问题就会更难一些。对于 Flaky tests 怎样处理比较好？删除还是进行标记使其不中断后续的测试且不影响质量门禁？A：Flaky Tests，就是指在被测对象和测试条件都不变的情况下，有时候失败、有时候成功的测试。因此，Flaky Tests实际上就是不稳定的测试，或者随机失败(随机成功)的测试。测试金字塔之所以是正的三角形，核心理念是越往上，即金字塔顶端的测试，其跨度越大，影响面越大，一旦出现问题，爆炸的半径也会更大，在这个层面做测试投入产出较小，工作量大且很难执行，比如测试故障定位等，而且自动化用例的复用程度或稳定性也较差，维护成本也比较高。当然该做的工作一定要做，但相对而言，建议这个层面的测试数量要适当减少。相反，越往底层，比如单元测试，爆炸半径相对就小一些，复用度和投入产出比也更高，而且在这个层面发现的bug应该是最多的。建议金字塔底层的测试措施应该相对多做。中间比如接口测试或跨组件的集成等，如果微服务拆分相对颗粒度小一些，各方面相对就比较好，且接口测试相应的工具也比较多，投入产出比也会越来越大。接口测试也可以多做一些，这样中间层变大，金字塔也会变成橄榄球形。Q37：构建本地持续测试和云上持续测试的对比难易程度和成本，如何选取？A：本地持续测试和云上持续测试的差异在于：本地需要自行对工具和版本进行维护，云上的环境相对快捷。从成本方面考虑，云上是按需的，性能测试、压力测试等适合在云上进行，因为自己去搭建一套10万/100万并发的环境成本非常高；越往前端的测试频度非常高，适合在本地进行构建。另外还需要综合考虑开发人员的使用习惯、公司对于数据的安全要求等进行选取。Q38：从传统的瀑布型测试到敏捷测试再到DevOps，三者之间具体有什么区别？A：瀑布型测试是在开发完成交付以后才进行完整的测试，测试主体是测试人员；敏捷测试往前走一步，做大量的持续集成等实践（如果敏捷实践不只是在管理层面的话）；DevOps是全流程测试，除了测试左移外，还有测试右移，频繁地持续部署到准生产或生产环境上去跑相关测试，甚至还有现网测试，包括混沌工程、Chaos monkey等，其概念更广。DevOps信奉Resilience（韧性），测试这件事很痛苦，我们要频繁地去做。和反脆弱的概念比较一致，“一切杀不死你的让你更坚强”。Q39 在测试自动化环节中应该如何简化测试流程又能快速发现业务风险？A：测试流程未必会简化，所谓的简化应该是指人员参与的流程减少，把大量能够让机器完成的工作交给机器、回归测试等实现自动化，将人从枯燥的重复性的测试活动中解放出来，去做一些新型测试的探索。Q40：SRE和DevOps有什么区别和联系？A：DevOps通常由两种角色去发起，Dev和Ops，即开发和运维。SRE是Google首先提出的一个概念，Site Reliability Engineer（网站可靠性工程师），从Google运维体系出来的一个角色。SRE工程师会通过自动化工具帮助开发人员，以运维的角度去参与研发并提供一些支持，包括开发一些自动化部署及运维相关的工具，通过这些工具和流程使能开发人员。两者比较而言，DevOps概念和范围相对更大一些，SRE则聚焦在开发与运维层面。Q41：在Scrum中只有 Dev team，没有专门的测试团队。“做测试者胜于做检查者”也要求测试人员不仅能发现问题更要准确定位问题。持续测试向价值流持续交付的两端延伸，要求测试人员不仅要懂业务、懂开发还要懂运维，对测试人员的要求很高。在这种背景下，测试人员该如何进行职业发展规划？A：确实测试人员的焦虑相对更多，因为不管流程也好、角色分工也好，他都处于开发和运维之间的位置，像三明治一样，比较难受。换个角度来看，测试是承上启下的活动，DevOps或敏捷在开始的时候都会相对顺利一些，短期成效很快，但等真正进入到测试层面，就像进入深水区，推进变得困难，原因可能就是自动化测试没做好。这样看来测试人员或测试活动其实大有可为，我们强调测试应该是一类活动，分配在整个研发生命周期过程中，而不是中间的某个阶段，因此对测试人员的要求当然也会更高。以往测试人员给人的印象是在研发提交后才参与进来，或者大量通过手工界面的点击去做回归等工作。现在和未来，这类测试人员存在的价值会很低，未来可能会要求测试人员懂业务，从业务的角度设计测试用例；还要懂开发，需要写测试脚本；还要懂运维。其实这些要求对所有的工程师都同样存在，包括开发工程师，要会做架构、做设计、做开发、还可能要自己做测试、部署运维等；运维工程师也是如此，如果转型SRE工程师的话，也要往前段去走。从这点来看，大家都在同一水平线上，所有人都要求往T型人才发展。综上，测试工程师应该是一个全程的质量保障人员，要从专业测试的视角对研发流程、需求、交付等进行质量控制，还需要引入相关实践、开发工具或做工具集成，去赋能开发和运维。真正好的测试对整个团队的帮助和提升应该是最大的。Q42：与传统项目比较，在敏捷项目中，测试工作在整个流程中所占的比重是否更少了，频次更高了，这是否意味着人效更高了？在DevOps流程下，产品人员、开发人员、主导测试人员的比例是否有一个新的经验参考？A：与传统项目相比，敏捷项目中，测试工作比重更大、频次更高、人效也会更高，但这个更高不是通过人去堆，而是通过自动化工具或时间来完成。在DevOps流程下，专职的测试人员数量会下降，现在大量的开发测试是由开发人员来做，在华为内部称为开发者测试，强调开发人员自己去做测试，以前开发测试比例差不多是3:1， 甚至1:1，现在可能是5：1或10:1的比例。产品人员跟以往应该没有太大差异，现在强调产品思维、运营思维，业务运营人员的人数会增加。Q43：小团队（5人，分工：2前端，3后端，没有专业测试人员）需要单独配备测试人员吗，一边开发一边测试，还是每个人对自己代码负责最后一块集中测试。这两种哪种好一些？A：个人认为5人团队没有必要配置专职测试，可以先由开发承担测试，当团队认为需要有一个专业的测试去知道或支持时，再去引入专业测试人员。那端到端的测试谁来做？建议是采用轮岗机制，类似on call，让团队成员轮流去做，这样可以让所有人对完整的测试都有了解和重视。Q44：未来是否会研测一体化？A：我认为研侧一体化会是一个趋势，开发者测试或开发测试的比例会越来越大，且不断往前端延伸，社会分工本就是合久必分分久必合，大分工衍生了一些新的概念，专业的人做专业的事，驱使我们更聚焦于自己的业务本质，比如IaaS（基础设施即服务），运维/环境管理、系统管理等会有专业的人去做，可以看看你是否就是这样一个专职的人才；测试也是如此，比如TaaS（Test as a service），也是一个非常专业的领域，要求懂开发、懂业务、懂运维。再有就是看公司的核心业务是什么，很多公司都不是专门做测试、运维或工具的，我们应该专注聚焦于公司主营业务。【五、持续安全与审计】Q45：如果组织中缺少专业的安全与审计人员，应该如何去补足这方面的能力？A：有些团队会把这个能力转移给相关的SaaS服务平台或第三方厂商。但平台只能提供问题的展现，实际的安全审计处理还需要专人进行。团队规模小时，可以通过业务上的分割和一些工具手段，尽量减轻相应人员的压力。Q46：小团队安全管控得太严格了，对开发测试都会造成很多不便，也会影响问题排除追踪，如何合理度量安全管控？A：项目进入正规化流程后会有很多环境：开发环境、测试环境、类生产环境、生产环境等，可以采用多环境不同程度安全管控的策略，比如在进行开发环境测试时安全管控力度可以松一些，类生产环境测试时安全管控严格一些。【六、持续部署与发布】Q47：持续部署是不是可以做到热部署，不暂停业务直接通过流水线进行部署、提供用户体验？A：持续部署，每一次变化都是直接部署到生产环境里，但持续交付是有一定选择性的，我们可以选择性地把一些需要的东西部署到生产环境中。如果希望可以做到热更新、热部署，不暂停业务，可以通过持续部署的方式，直接使用流水线来实现。Q48：K8s和Docker在应用上有什么区别？A：Docker是一种容器技术，在实践中可以直接使用Docker进行镜像构建等操作；K8s是进行集群管理的技术手段，华为云DevCloud的帮助中心有一个凤凰商城的实践案例，和HCIP考试中的实验一样，只是多了CI/CD的环节，在这个环节中就使用了K8s。Q49：K8S 和 云原生是什么关系？A：云原生是包括微服务、DevOps、容器化、持续交付等理念和方法，K8s只是一个集群管理的工具。 Q50：如果生产环境有等保要求，还有什么办法实现持续部署吗？A：如果生产环境有等保要求的话，不太适合直接做持续部署，这时使用持续交付的方式更好一些，我们可以先决定应该把哪些特性搬到生产环境上去。Q51：新版程序修改了数据结构，如何进行应用设计或部署方案，以应对可能出现重大问题所需要的版本回退？A：当我们做一些比较大的修改时，一般会先部署到类生产环境上，检视没问题后才会通过灰度的方式同步到生产环境中。Q52：我们已经在做持续集成了，但持续交付和持续部署应该怎么落地？A：如果已经在做持续集成，且做得比较成熟了的话，再往前落地持续交付和持续部署会相对容易。我们经常说：持续交付只是持续集成往前的一小步，最后一公里或最后一米会比较痛苦。其实更多的痛点不在于技术层面，而是在于流程、制度层面，可能很难打穿部门墙、穿透企业管控类的要求，这些都未必是技术能解决的问题。【七、持续运维与监控】Q53：通过自动化的方式实现持续集成和持续交付，中间会不会出现干扰而发生错误？A：一般来说，通过自动化的方式实现持续集成和持续交付后，不是很容易发生错误。错误的出现可能是由于配置问题导致的，在配置相应流水线时没有配置好，比如参数出现问题，版本变得不一致等。除此之外还可能会有一个意外导致的问题，比如网络故障等。Q54：如果生产环境要求网络隔离，还有什么办法实现持续部署吗？A：如果生产环境要求网络隔离的话，我们的流水线一般会搭建在公司内部，也就是从提交代码到构建部署都会在公司内部实现。这个过程中使用云上自动化产品会少一些，因为目前大部分云上构建的工具都必须访问公网才可以做到流水线的效果。因此这种环境下，建议在本地搭建自动化构建流水线，或者购买可供私有化部署的工具。也可以在公网进行代码托管和构建，只在部署的时候通过手工部署的方式将软件包放到网络隔离的机器上去。Q55：Docker与虚拟机有何不同？A：从上图可以用比较清楚的看到Docker和虚拟机的异同。左边的VM是虚拟机使用，container是容器使用，也就是我们说的Docker。两边都有server端和Host OS（虚拟机上的系统）。我们知道每个APP上都有Bin/libs，在Docker容器技术环境下，相同的APP可以共用同一个Bin/libs。大大节省了所占的资源空间。【八、DevOps实践与转型路径】Q56：到目前为止，已经学习了很多DevOps的功能，但是有一个困惑，对于使用DevOps是零代码，那么对于专业的开发人员来说，会不会慢慢降低他们的代码开发积极性？A：DevOps提供的零代码是指在整个DevOps工具链中希望是零代码的，通过将一切可自动化的工具自动化，将开发人员从各种维护工作中解放出来，使他们专注于开发。Q57：在DevOps实践中，环境差异的问题需要在哪个环节就开始着手来注意减少或者避免？A：配置即代码，在开发环节配置差异化的时候把环境差异等都配置进去。Q58：在DevOps转型过程中，对组织和团队最有挑战的有哪些？A：我认为DevOps转型最难的有两方面：一是如何争取公司高层同意推动DevOps转型；二是如果请了教练/顾问协助DevOps转型，顾问/教练走后，如何继续保持和落地DevOps实践。Q59：小团队如果想要使用DevOps需要全员学习吗，感觉每个人都学习时间成本挺高的，是否可以专人负责特定阶段？A：团队如果想要进行DevOps转型，需要专门有一个人把这些流程和工具研究明白，或者聘请一位外部DevOps顾问，再由整个专职人员或DevOps顾问在整个团队进行培训和推动。Q60：四个闭环过程中遇到困难或者难点是否可以列举？有什么避免的方案？A：先回忆一下四个闭环过程：l   第一阶段闭环：需求开发测试融合，将产品、研发、测试等角色融合，组建跨职能团队，提升产品交付价值与质量； l   第二阶段闭环：开发测试融合，组建研发部门内部的跨职能团队，提升自动化水平，降低修复成本； l   第三阶段闭环：研发运营一体化，实施产品自运营、自运维，打破了市场、研发、运维部门之间的壁垒，更多角色融入交付链路，提升业务响应力，建立价值反馈流； l   第四阶段闭环：目标是逐步实现所有业务线都以跨职能团队为最小组织单元，实现业务敏捷性，持续提升企业的市场竞争力。难点包括：l   打通需求难。产品侧和研发侧沟通难。在传统瀑布模式下产品和研发的沟通存在很多问题，比如需求沟通不明确等，引入敏捷的计划会议，在计划会议上做需求澄清，可以解决这一难题。l   开发测试融合难。在很多公司这是两个团队，还有些公司没有测试的角色，要进行人员和过程的融合比较困难。l   研发运营结合难。研发运营一体化，运营部分的内容怎么跟开发结合也是一个难点。l   组织结构管理难。整个流程打通了，人员的管理和组织结构的变动方面也可能会存在问题。以上难点需要根据公司具体情况来实践和探索最佳解决方案。+小姐姐微信加入训练营交流群

加入专家交流群：1.get最新最全的学习资料和开发小技能；2.与各位专家一同探索交流产品；3.最新的产品活动微信提醒您，重要信息不错过；欢迎加入开发者专家交流群，一起探索交流！！！

--------活动已结束--------2020 华为12月29日（周二）早上9点到下午5点30分，进行全天线上直播，汇聚多位华为重量级专家看行业趋势、玩闯关游戏、赢贺岁礼包直播地址回顾中...专家介绍四重福利，助力云筑2020 年终盛典直播启幕！！！福利一：成功报名本次直播盛典，必得200码豆福利二：12月29日参与直播盛典互动，直播间内抽取平板电脑、手表、耳机等数十件奖励！福利三：参与直播现场连线，完成闯关答题，赢取六重“包您一年系列”大礼！福利四：邀友报名直播盛典，Ta得超级贺岁礼包，你也同样获得！- 如何邀请好友？1.点击本页面上方“立即报名”按钮 > 2.登录/注册华为云账号 > 3.填写信息完成活动报名 > 4.报名成功弹窗中点击分享有礼(或进入我的直播中点击分享有礼按钮) > 5.按照引导将活动分享至你的好友，并引导ta完成本活动报名参与专家坐堂互动在本帖下方任意回复以下一项内容，即有机会获得FreeBuds 悦享版 无线耳机和定制双肩包。有效参与楼层的5%、50%、95%必得三合一数据线。*奖品样式为示意，请以实物为准（任选其一）参与互动1）  观看直播后发表您的个人观点2）  观看直播后向专家提出问题3）  参与微话题互动：讨论话题：你觉得NLP技术之后会如何融入我们的日常生活？注：发布的内容必须与本次直播话题或微话题相关，且必须包含个人思考的内容。水帖将做删除处理，抄袭内容一经发现将取消评选资格。回复时间截至2021年1月10日。活动规则1、如本帖的有效回复人数大于等于20人，则由专家和华为云工作人员共同评选出3个优质回复，发布者可获得定制双肩包一个。如有效回复人数大于等于30人，则额外评选出一个最优回复，发布者可获得华为freebuds 悦享版 无线耳机一个。如有效回复人数小于20人，则只发放三合一数据线。2、每位参与本帖活动的用户只能获得一次奖品，每人最多回复同一内容5次，如果有恶意灌水的行为将取消获奖资格3、如您参与云筑2020年终盛典，为保证您顺利领取活动奖品，请您提前填写下方奖品收货信息链接，如截止2021年1月17日您没有填写，视为放弃奖励  填写地址请戳我>>4、本次活动奖品将于2021年1月31日前统一发出，请您耐心等待；5、本次活动抽奖将采用巨公摇号平台（https://www.jugong.wang/random-portal/），奖项评比将由专家和华为云工作人员共同完成。如您对评奖方式有异议，请勿参加本次活动。点击前往云筑2020 年终盛典更多活动

--------活动已结束--------2020 华为12月29日（周二）早上9点到下午5点30分，进行全天线上直播，汇聚多位华为重量级专家看行业趋势、玩闯关游戏、赢贺岁礼包直播地址回顾中...专家介绍四重福利，助力云筑2020 年终盛典直播启幕！！！福利一：成功报名本次直播盛典，必得200码豆福利二：12月29日参与直播盛典互动，直播间内抽取平板电脑、手表、耳机等数十件奖励！福利三：参与直播现场连线，完成闯关答题，赢取六重“包您一年系列”大礼！福利四：邀友报名直播盛典，Ta得超级贺岁礼包，你也同样获得！- 如何邀请好友？1.点击本页面上方“立即报名”按钮 > 2.登录/注册华为云账号 > 3.填写信息完成活动报名 > 4.报名成功弹窗中点击分享有礼(或进入我的直播中点击分享有礼按钮) > 5.按照引导将活动分享至你的好友，并引导ta完成本活动报名参与专家坐堂互动在本帖下方任意回复以下一项内容，即有机会获得FreeBuds 悦享版 无线耳机和定制双肩包。有效参与楼层的5%、50%、95%必得三合一数据线。*奖品样式为示意，请以实物为准（任选其一）参与互动1）  观看直播后发表您的个人观点2）  观看直播后向专家提出问题3）  参与微话题互动：讨论话题：你最期待2021年应用开发领域发生什么变化？注：发布的内容必须与本次直播话题或微话题相关，且必须包含个人思考的内容。水帖将做删除处理，抄袭内容一经发现将取消评选资格。回复时间截至2021年1月10日。活动规则1、如本帖的有效回复人数大于等于20人，则由专家和华为云工作人员共同评选出3个优质回复，发布者可获得定制双肩包一个。如有效回复人数大于等于30人，则额外评选出一个最优回复，发布者可获得华为freebuds 悦享版 无线耳机一个。如有效回复人数小于20人，则只发放三合一数据线。2、每位参与本帖活动的用户只能获得一次奖品，每人最多回复同一内容5次，如果有恶意灌水的行为将取消获奖资格3、如您参与云筑2020年终盛典，为保证您顺利领取活动奖品，请您提前填写下方奖品收货信息链接，如截止2021年1月17日您没有填写，视为放弃奖励  填写地址请戳我>>4、本次活动奖品将于2021年1月31日前统一发出，请您耐心等待；5、本次活动抽奖将采用巨公摇号平台（https://www.jugong.wang/random-portal/），奖项评比将由专家和华为云工作人员共同完成。如您对评奖方式有异议，请勿参加本次活动。点击前往云筑2020 年终盛典更多活动

有大佬参加“专家手把手传授EMQ X 快速搭建物联网平台”活动吗？说好的送码豆怎么我还没收到，大佬们有收到的没？

到2020年底，全球217亿个连接设备中，有117亿将是IoT设备连接。这一数据来自IoT Analytics，并预计到2025年，受5G等新技术推动，将有309亿台联网的IoT设备。从2005年11月17日，ITU正式提出“物联网”概念，到2009年物联网被正式列为国家五大新兴战略性产业之一，写入十一届全国人大三次会议政府工作报告。物联网被称为继计算机、互联网之后，世界信息产业的第三次浪潮。时间和技术出现浪潮，当然也会出现一些弄潮儿，连利波就是其中一位。对IoT的热爱：将兴趣做成事业，连利波在研究生期间学的是控制工程学，但他却对嵌入式开发十分的感兴趣，在大学期间就开始研究嵌入式开发。在2010年，那个时候还属于物联网发展的第一阶段，越来越多的设备通过移动网络、Wi-Fi、蓝牙、RFID、ZigBee等连接技术连接入网。在当时，连利波还猜测ZigBee通信技术可能会在智能家居这个领域应该会火爆起来。毕业之后，在2017年连利波进入物联网圈子。17年的物联网通信在用LoRa技术，它的传输距离远，城镇可达2-5 Km，郊区可达15 Km。在惊讶技术的进步同时，连利波对物联网的发展也更加关心了。随后在2018年的时候，正式接触和应用NB-IoT通信技术。随着学习和使用的不断加深，华为云IoT平台上的产品和技术吸引到了连利波。他利用华为云推出的IoT课程和实践内容，在华为云老师的帮助下，逐渐掌握了NB-IoT通信的特点和优势，让连利波对华为云IoT平台有了更深的认知。连利波利用自己的所学知识，在2019年的华为开发者大赛IoT赛道获得优胜奖奖励。从事物联网工作3年以来，连利波和团队同事共同努力，开发了基于LoRa的用电数据采集系统，并完成了基于信噪比优化的LoRa组网算法。连利波团队还联合华为推出了基于NB-IoT的智慧园区能效管理解决方案，开发出多个能耗采集系统的建设，分别在西安、成都、深圳、佛山等地落地。不仅如此，连利波团队还开发出多协议多通信方式的物联网采集终端并获得专利，实现了传统透传方式的采集系统到自主可控采集系统的转变，极大节省了物联网通信带宽和费用。建设不是核心，融合才能创造价值相比较早期，物联网通信技术有了很大的进步，但缺乏行业标准，体现在传感器、模组、平台、应用等方方面面。连利波讲到，仅仅是换一个模组，不是要改硬件，可能就是要修改软件。而且，在感知层的设备协议更是五花八门，就一个设备（除国家电网定义的dlt645协议外），每个厂家的协议都是不同的，用户要做各种协议解析。不仅如此，物联网平台也只是规范设备接入自家平台的协议，不同平台之间的互通性很差。其实，通信技术并不是当前物联网发展的瓶颈，而是在于要去发掘客户真正的需求，只有认真了解了需求才能够真正解决用户问题。一个设备要接入网络并不是什么复杂的事情，物联网只是基础建设，不同行业数据的融合才可能为用户创造出价值。并不是一个设备接入互联网，就简单远程控制一下。现在的物联网建设，仅在设备适配与改造方面就已经让用户付出了很大的成本，不同厂家的设备平台又很难互通，收效甚微。必须要逐步建立统一的标准才有利于物联网的持续发展，而这需要各行各业的通力协作，也更需要我们一起为物联网的良好持续发展贡献力量。

随着过去几年传感器和终端设备长足的发展，加上通讯连接在带宽和速度上的大幅提升，物联网 IoT 得到了前所未有的推进。5G的迅速崛起，IoT技术应用也呈现出前所未有的态势。作为一个有着18年工作经验的“老”程序员，李万龙虽然一直从事软件工程方面的工作，但他心中一直有软硬件结合的梦想，尤其近几年物联网概念再一次风靡，他更是蠢蠢欲动。但既往的工作内容和经验都和嵌入式开发无关，对于物联网的相关开发，有点无从下手。2019年4月一次偶然的机会，他看到华为云物联网平台提出的1+2+1战略。于是，李万龙抱着看一看的心态浏览着华为云物联网论坛。也正是这个无心的浏览，李万龙发现论坛正在举行“IoT在线训练营”活动，该活动主要介绍华为物联网+LiteOS+小熊派的技术学习。李万龙当时就激动了起来，这个线上培训有案例有老师，就是他梦寐以求的软硬结合的物联网场景。于是，他立马注册了账号报名参加活动，下单购买小熊派硬件设备，开启了他的物联网之路。跨过零，走进物联网毕竟是第一次接触物联网，李万龙在一开始除了物联网这个名词，其他的都不了解，设备端的开发都需要从零开始。李万龙表示，在学习的过程中，华为云老师准备的课程非常全面和干货。李万龙从物联网的概念开始，认识了物联网的起源与发展，学习了华为IoT的组成和使用，尤其是LiteOS物联网操作系统，这是华为云在各大物联网平台最突出的一点---物联网操作系统，结合小熊派案例的演练，在短短2周的学习中完全掌握了基本的应用。并且结合自身工作经验对业务方案设计能力，把身边一个典型的场景，用物联网方式设计出了整套解决方案--智慧校园案例，此案例在培训学习成果的评比中获得一等奖。实践出真知，圆物联网之梦也正是得益于这两周华为云课程的学习，让李万龙从一个门外汉，轻松入门物联网领域。随后在华为云IoT培训老师魏彪的鼓励下，李万龙参加了2019年度的开发者大赛。对于当时李万龙来说，感觉自己的水平离参加大赛还很远。尽管用Demo在培训成果评比获得一等奖，但毕竟不是产品。于是乎，李万龙下定决心用两个月的时间，通过更加深入的学习物联网知识，结合华为云IoT平台，把这个智慧校园的Demo做成一个可以上线的真正产品。经过不懈努力，李万龙这个过程中完成了华为云物联网平台的南向设备接入和北向应用接入，一个物联网应用产品雏形已经完成了。端到端设计示意图第二版服务能力设计为了打造优秀的产品，李万龙在华为云IoT平台上继续学习新的接入和产品场景结合技术，终于把原始的Demo做成了一个可以面向用户的上线产品。为了能够正式运营正式注册了公司，李万龙申请了产品商标--家校物联(家校互通、智在物联)。不仅如此，这个产品还顺利入围2019年度华为云开发者大赛IoT赛道的决赛，并在华为东莞总部决赛中获得优胜奖，这一次经历也让李万龙真正从互联网实现了物联网梦。自从跟随华为云物联网学习以来，李万龙在学习新知识上就像一块吸水的海绵，每一段吸收都是满满的能量，当然这段过程也很痛苦，当时课程的Demo多是C语言和Java语言，而李万龙最熟悉的却是.Net。.Net跨平台也是近2年的发展，除了理论所能借鉴的代码却没有，在论坛上也常有人问.Net平台C#如何接入华为物联网，但无人回答之。虽然物联网平台的接入是和语言无关的，然而却无人在这个语言上提供可参考的案例。李万龙决心根据接入接口打造一个.Net接入的案例，为社区的小伙伴尽自己的绵薄之力。回头总结起来，李万龙表示，物联网无非是物与物相连的互联网，把哑终端变成主动和上级服务互动的智能设备，随着5G和AI的发展，物联网的接入设备更加丰富，终端能干的事情也越来越多，终端也越来越智能化，IoT边缘计算的概念随之而来，万物互联也正在走向万物智联。李万龙在完成了IoT在线训练营后，发表了首篇华为云社区博客和项目帖子，详细介绍了.Net平台用C#语言如何完美的接入华为物联网。在开发者大赛准备过程中也完成了南向设备.Net环境MQTT协议的接入，在论坛上分享了自己的劳动成果。从0到1，师父领进门修行在个人从0到1，也是从无到有的过程，是重要的知识学习，掌握技能，这个过程的起始是困难的。从0到1的实践非常重要，相当于成功路上的第一桶金，也正体现了华为学习课堂的重要性。虽然互联网上的知识点很多，但是都很零碎，反观华为云课堂的课程学习知识系统，条理清晰，知识也能扩展得更多。从1到n就是技术的实际综合应用，这个时候就需要各个知识点的串联，在1个案例中应用成果，可以复制到n种场景、n个行业，让学到的知识开枝散叶，这就不仅仅需要训练营学到的知识，还需要行业知识的深耕，师傅领进门，真正的修行还要靠自己实干。在2019华为开发者大赛决赛现场，李万龙感受到IT精英们年轻的朝气。作为在参赛者中是年龄最大的，业内一直再说“IT人35岁后在技术革新中落伍了，要退休了”。站在领奖台上的李万龙从来不相信这一套，他掀翻35岁IT人退役魔咒，站在巨人肩膀上，应用新技术，结合经验，整体方案优势，让IoT快速生花，这就是李万龙得最新感悟。

与其说传感器是一个硬件设备，不如说它是我们人体感官的延伸。试想一下，我们被丰富且微小的传感器所包围，它们时刻监测我们健康，通过云端算法，如同加密的 “私人医生”一样，帮助我们预防疾病风险；城市和生活也会被丰富的传感器网络所包围，时刻检测温湿度、空气质量，由此开启和关闭空气净化装置，实时改善城市的环境……这也是刘文龙所构想的物联网世界，他认为未来的世界，传感器将包含人类五感的功能，部分甚至能代替和制造五感的效果。那么，这样一个有些“荒诞”，又有些“理想化”的世界，从哪里开始呢？与IoT结缘，感知世界的另一种方式刘文龙算是物联网行业的老兵了，在嵌入式领域有着10多年的工作经验。他和物联网的渊源最早可以追溯到他上大学那会，回忆起当初做物联网开发的那段经历，刘文龙提到了一个有趣的项目。当时他在学校实验室开发一个精密的形变检测产品，用于测试大坝微小变化。其原理是利用24位AD对一个形变片上的微小电压进行测试，采样后利用Δ-∑滤波器进行滤波，然后通过MCU进行中值处理后得到一个新的数据点，最后将数据发送到中央监控器，监控被测物体微米或是纳米级别的形变，来预判一些事故的发生。可见一个小小的传感器蕴藏的能量是不可估量的，刘文龙迷恋于此。所以，毕业后他一直从事嵌入式开发的工作，尤其以伺服嵌入式软件开发和物联网应用开发为主。10年的行业经验，也让刘文龙对物联网市场的变化感同身受。        单一的传感器能收集到的数据是有限的，以前也没有合适的技术能将这些数据价值最大化。但通过物联网技术，可以把传感器的参数采集后通过安全加密的方式传输到云端，在云端大数据和AI的支撑下，赋能这些传感器。最终，无处不在的IoT设备让我们更好地控制和感知我们的世界。在刘文龙看来，IoT无处不在，用于测量空气的温度、湿度、PM2.5，用于生产安全的燃气浓度、烟感等等，更多智能的传感器和云端算法正融入到我们的生活。LiteOS：速度快、周期短、高可靠工欲善其事必先利其器，万物互联的美好图景始于物联网应用的开发，这也是刘文龙接触华为云后最受益匪浅的地方。他在学习华为云IoT课程时了解到华为云的嵌入式操作系统LiteOS，自此就是一发不可收的项目开发之路。在刘文龙看来，LiteOS可以很好地进行实时线程的控制，首先保证了传感器采样对时间的要求。其次，LiteOS的设计能够加速开发者项目的落地，以它提供的传感器框架为例，由于统一了接口，开发者选择已有的传感器驱动进行开发或是依照框架设计传感器驱动时，能直接调用应用程序，不仅缩短开发周期，也减少不靠谱代码造成的影响。刘文龙举了个开发实操的案例：利用SR04超声波传感器进行距离采样。如果使用原有的裸机开发，需要自己做定时的采样，开启定时器中断，然后检测中断的时间，按照这个时间计算处理，再通过时间扫描将数据发送到云端。但是用LiteOS后，我只需要把SR04的超声波检测模块添加到SensorHub框架，然后利用轮询传感器采样，将数据转成Json格式直接发到云端。这几步操作只需LiteOS创建几个线程，写几行语句就能实现，比原有逻辑的开发思路简单多，再加上华为在安全上做的工作，还能保证运行后的可靠。更优秀的是，华为在保证系统足够安全可靠的情况下，还增加了IoT Studio数据平台的服务接口，这样从数据采集、网络协议（MQTT、CoAP等）传输到IoT Studio也只要几行指令即可完成。软件的便利性让刘文龙颇为感慨，“这在原有的嵌入式编程上是不可想象的，华为云IoT工具的效率和安全性并重，既降低开发者的使用门槛，也给嵌入式设备更好地赋能。”现在手上有新项目，刘文龙第一考虑就是LiteOS，它既有优质的框架能直接选用，也可以更好得完成项目算法的迁移。经过几个项目的历练，刘文龙认为，“未来嵌入式MCU必将从裸机开发到RTOS开发，因为现在的程序可靠性高，编程也简单，相应的项目产出也快了。”不过，LiteOS解决的只是物联网应用的开发，真正让传感器智能的还要靠设备（数据）上云后带来的数据价值。IoT+AI赋能，让设备“活”起来数据上云后，用传统的方式面对这些数据感觉很无力：既没有好的大数据算法，也没有相应的大型服务支持。但现在有了IoT数据接入服务DIS，一切难题便可迎刃而解。DIS可以连接AI开发平台ModelArts实现AI的运算，并把结果反馈回IoT平台到开发板进行命令执行。具体流程如上图所示：边端设备将数据传输到IoT 平台，数据以JSON格式转入到DIS，再通过对象存储服务OBS将边端数据传送到ModelArts，数据经过预先制定的边端模型训练后在AI开发平台上实现功能。这就是从端边的数据采集到云端AI运行，再将结果输出到IoT平台监控和终端设备执行命令的全流程。以此类推，在智慧城市、智慧工厂这样大的场景中，我们也可以将传感器收集到的数据加载到AI模型中，从而预判场景的变化，如城市人口的移动数据、各个景点空气质量数据、工厂的生产进度……这样就能高效地进行城市建设，为工厂设备的使用进行预判维护，提高生产力和效率。可以预见的是，伴随着云服务、AI、边缘计算的深入结合，万物互联，以传感器为代表的物物感知时代，离我们真的不远了。

IoT并不是一个新名词、新技术，很长一段时间，它甚至给人一种“下工地”的印象：由于IoT设备的落地场景经常与工程环境强相关，又不容易远程配置，所以难免“形象不佳”。近几年，当IoT与创新、科技、互联网等挂钩时，成为一个相当“新锐”的行业，尤其云计算时代的IoT，有了许多让老树开新花的功能，也让这个行业有了许多新的想象空间。比如，Serverless、微服务，这些新技术和IoT有什么关系？纵观IoT行业的发展，云服务又扮演了什么角色？华为云云享专家董昕以业内人的视角给出了他的理解。董昕是个喜欢折腾的人，既在Intel、中国银联、Trident这样的大公司待过，负责芯片、IoT、安全、云计算等多个领域的技术开发；同时，他也是一个连续创业者，肩挑背扛整个公司的技术架构，所以对中小企业在信息安全和云计算上的紧迫感有着深刻的认知。如今，董昕担任国内某大型第三方支付公司的高级架构师，一直处在技术一线的他，对当前IoT行业的发展有着理性的洞察，以下是他对IoT技术发展趋势的一些预判。 物联网比互联网更适合ServerlessServerless即开发人员无需再关注服务器的运维工作，直接将代码部署在云端，对外提供RESTful API 即可，云计算会自动根据请求编排资源。这种模式非常适合前端实现许多功能、后台记录状态的场景，可以说是大前端发展的必然趋势。在董昕看来，目前各大云服务商针对IoT设备提供的物模型，本质上就是一种Serverless，甚至更进一步，已经是Codeless了。沿着这个思路去考量互联网和物联网在Serverless上的差异，会发现 IoT 仅仅只是将联网的主体从人改成了物，而消息的请求与响应并无差别。甚至在大多数情况下，联网的物比联网的人，要更容易数据化，所需提供的服务也更单一，几个属性和服务就足以清晰的定义某类IoT设备。所以从这个角度看，物联网比互联网更适合Serverless这种模式，而物模型就是这种模式在IoT上的落地形式。Serverless 的发展趋势、优势与目标都可以匹配IoT，比如海量接入、快速扩缩容、可移植性等等。对于物模型，我们可以做与当下的Serverless几乎一致的畅想，把Serverless上的经验全盘复制到IoT的场景中，比如Serverless中最迫切的代码可移植性问题。站在云服务商的角度，用户建立了物模型，就是与云服务商进行了强绑定。可对于普通用户而言，物模型的可移植性，甚至是物模型的编排工作，都是要解决的难题。如同 Serverless已涌现出了数家跨云服务商的中间件提供方一样，伴随着IoT的发展，物模型的编排将很可能将会成为开发者值得去探索的方向。另外，在Serverless上暴露的物模型组件的继承与复用，传统代码与物模型之间的转译等问题，在IoT的将来都会是无边无际的蓝海，同时还有互联网软件的前辈们留下的宝贵经验，广阔天地，大有可为。硬件正在不断的软件化，这个观点早已不再新鲜，但仍未过时。软件中的许多设计思想，都值得在硬件设计中去复制与实践。 每个IoT设备都是一个独立的微服务 “微服务”是软件行业里很热门的一个词，即把一个大的功能模块拆解成数个小的，然后在整个系统中，小模块可以合并、复用。微服务各司其职，大系统化整为零。这样做的好处很多，但维护管理众多的微服务成了一个麻烦事，于是就有了Docker和 Google发布的微服务治理框架Kubernetes。延续前文提过的“硬件正在不断的软件化”思路，每个IoT设备，从功能目标上看，都可以看作一个独立的微服务，所以软件微服务治理的那套规范一样可以运用到IoT设备上。比如华为开源的KubeEdge项目——这个项目可以将容器化应用程序编排至边缘主机上，让每个边缘主机化身为微服务节点。准确的说，KubeEdge并不是部署在IoT设备上，而是针对边缘计算端的，毕竟目前绝大多数IoT设备的算力还不足以支持。边缘计算节点作为IoT网关，联合各种终端IoT设备，已经完全足够成为一个微服务节点，也让算力能够提供更契合场景的定制化输出，而非单纯的依靠软件提供标准化产品。类似的，在边缘节点成为硬件的微服务节点之后，软件微服务治理的设计思想也可以移植到了边缘计算当中，包括但不限于：CI/CD、DevOps、ServiceMesh、服务监控与追踪，甚至AIOps等等。我们时常说的“端边管云”也只有在这样的基础上，才能真正实现无缝连接、自由组合、实时配置等。至彼时，IoT的工作模式就仿佛人类社会分工的某种终极形态：各个终端设备都具有能独自解决某类问题的能力，又可以随时与周边的其他设备组建团队解决棘手的问题，还能够从云端实时得到更多重量级的支援——这哪里还是以前“不受待见”的IoT开发啊，完全是一支海军陆战队嘛！我来，我见，我征服。 鸿蒙之我见：江湖路远，吾道不孤鸿蒙虽时常被拿来与安卓对比，但它实际上是为IoT设备设计的，尤其是其模块化耦合的特性，完全是为IoT设备量身定做的。相对于电脑和手机，IoT设备缺乏统一的标准协议，每种设备都可能只具备某种特性实现为此，鸿蒙提供了对不属性的设备做定制化裁剪的功能，而对于硬件资源的多寡，鸿蒙又设计了多层架构，各种设备可以根据自身资源的情况选择不同的层数。简而言之，鸿蒙试图以一站式服务的方式，为各式各样的IoT设备提供从底层到应用层软件的全方位支持，让硬件制造商摆脱了软硬件双线作战的困扰，同时也为所有的 IoT 设备统一了标准与接口。实际上，意图统一IoT接口标准这一野望，安卓和苹果都曾以Android@Home和HomeKit的方式奢望过。但应者寥寥，归根结底，具备了软件开发能力的硬件制造商，即便是面对 Google和苹果这样能为其提供海量流量的巨头，也不愿惟其马首是瞻，从而最终彻底丧失独立性。而在软件上乏善可陈的制造商又难入巨头的视野，也难堪海量流量的冲击。于是，这种只定义接口让厂商自行实现的方式最终沦为一场双输的博弈，看似风光无限，实则互相提防。不只是系统设计，鸿蒙在功能特性上也为IoT设备提供了丰富的想象空间，比如分布式软总线。以往我们在讨论总线，都是在一个固定且封闭的硬件组合当中，比如电脑的南北桥总线， SoC芯片内部的AMBA总线——都是在一个封闭的硬件环境中，各功能模块固定不变的情况下，以硬件的方式实现的总线。而在鸿蒙的场景下，多个IoT之间是通过网络连接，各组件也随时都可能下线或属性变更。打个简单粗暴的比方，分布式软总线是要在把电脑拆散了，各个模块通过有线/无线的方式进行通信，且都支持热插拔的情况下，用软件协议的方式将各个模块串接起来，同时还需确保数据安全与读写效率。事实上，不止是华为，Google正在研发的新一代操作系统Fuchsia，本着一样的目标，也在积极推进中。星辰大海，百舸争流。  结语曾经，单独一个IoT设备既不起眼，还需要不少的人力维护，甚至必须到现场蹲点，实在是一个费力不讨好的行当。现在，云计算的浪潮正改变这个行业，星星之火，必将燎原。当老树发新芽，在新技术的加权下，如何把握IoT大势中新一轮浪潮，让我们拭目以待。

云原生、边缘计算，都是这两年的技术热词。那么，当我们从Cloud Native走到Edge Native，需要面临哪些挑战，它们各自的特点又是什么，IoT行业会迎来变革吗？且听华为云IoT服务首席架构师王启军慢慢道来。 我如何成为云原生的忠实信徒和布道者？写书、写公众号……王启军算是程序员中少有的，喜欢用文字记录工作和分享生活、心思细腻的技术大牛。在王启军的公众号中，他写过一篇《My Team》的文章，里面记录了早年带团队成长的心得。在推进华为云Cloud Native、微服务架构落地期间，他将自己积累的技术实践整理出一本书——《持续演进的Cloud Native：云原生架构下微服务最佳实践》。对于王启军来说，每接触一个新的技术领域，都是一次自我挑战和升华，随之而来的是越过高山的成就感，这股学习钻研的劲一直伴随着他工作内容的始终——从研究云服务架构到IoT。这个过程中，王启军也亲历了云计算行业的技术迭代变迁。在工作的前五年，他一直痴迷于技术在大规模、高并发、极致性能等方向，那时候既没有云原生，也没有微服务架构的概念，但实际上两者方向是一致的。当时王启军致力于用分布式、服务化、无状态、去中心化去实现一个高可用的系统；通过云计算、平台化实现能力沉淀，最大化重用；通过CI/CD实现快速反馈。但理想丰满，现实骨感。“到了一个新的环境，周边的人对这些并没有一个很好的认同感，存在很多质疑，这也很正常，只有确实经历过，才能义无反顾的坚持到底。”王启军在技术上有种初生牛犊不怕虎的冲劲和韧性在其中，偶然间他了解到云原生，一拍即合。“云原生从架构、流程、文化三个角度上很好的描述了我的想法。此后，我成为了云原生的忠实信徒和布道者。”那么，什么才是云原生？云原生又能给我们带来什么呢？王启军认为：云原生是一组最佳实践，如果你按照这种思想去设计、开发、测试、维护软件，能够发挥出云的最大价值，也就是说，你可以重用云的能力，站在巨人的肩膀上，更快速、更高质量的提供服务。如今，随着Docker、Kubernetes的飞速发展，云原生、微服务架构在技术领域可谓家喻户晓，也成为越来越多的互联网公司业务开发的首选。 从云原生到边缘计算，边云协同是趋势之后，随着王启军工作的变化，他开始将研究视角转到IoT领域。IoT的关键是每个单独智能硬件的互联互通，且要满足低功耗、低时延、高安全等要求，所以在IoT领域，边缘计算非常重要。举个例子，虽然越来越多的企业用云去替代传统的数据中心，但还是有很多业务场景没办法直接上云：数据比较敏感，例如园区涉及到个人隐私，工业涉及到商业机密；数据量非常大，如果上云，需要消耗大量的带宽，成本比较高；上云的时延会比较高。物联网下的很多业务场景都是如此。IoT主要连接各种各样的设备，然后把数据报上来，再给设备发送指令，这些设备的数据在某些场景下是敏感且重要的。也许会有人提议，既然上云不可行，那就自建数据中心，构建自己的私有云。但这种模式也存在各种问题：首先工作量巨大，其次不是所有团队都能做到更高的SLA，最关键的是它无法享受到公有云带来的体验。在公有云的模式下，不需要自己运维，服务会自动升级，还有云服务提供商保障业务的可靠、安全。在王启军看来，边云协同是最佳解决方案之一。“数据不上云，连一根线，远程运维、升级，你还是能够享受到云服务，数据又不会跑出自己的数据中心。这在物联网场景下是非常受欢迎的。”所以在IoT场景下，整体架构就分成了多层：公有云——混合云——智能站点——IoT边缘。其中，智能站点是华为云IoT在边缘侧的一个服务，类似于边缘云或者雾计算，通常3台物理机起步，可以处理边缘侧的大部分业务。另外，王启军还着重强调了华为云IoT的另外两个关键能力。1、什么设备都能接。物联网本质上是连接万物，目前整个行业的协议种类非常多，来自不同厂家的硬件，协议千差万别。如果基于这些硬件构建应用的话，仅适配的工作量就非常巨大，华为云IoT设备连接管理服务解决的首要问题就是什么设备都能接。2、什么场景都能接。华为云IoT服务支持公有云、混合云、边缘云、网关等多种接入方式，能够满足各种千差万别的应用场景。 边缘不会取代公有云谈到边云协同，就不得不提Edge Native，它是Cloud Native在边缘的一种延伸，除了继承Cloud Native的一些能力之外，Edge Native也有一些自己的特点：1、本地资源受限，无法弹性伸缩，可以把公有云作为一种扩展，无法像公有云一样使用额外的资源进行升级，只能滚动升级。2、扩展性要求很高，因为实际上边缘的场景很多，对性能要求的跨度很大，必须保持架构的扩展性以应对不同的场景。3、如果按照传统的运维方式，无法达到公有云的可靠性。Edge Native需要做到一键安装，极简运维，运维是它的核心能力，例如机柜断电、服务器故障，需要做到自动恢复。4、Cloud Native强调的是DevOps、快速反馈，而Edge Native升级限制比较多，没办法快速升级生产环境，需要有一套仿真环境让开发人员得到快速反馈。也就是说，“Edge Native”应用的一系列特殊需求，如离线自治、故障自愈以及超大规模节点管理等，对Cloud Native技术提出了更高的要求。如今，虽然边缘的势头越来越猛，但终归还是无法脱离云服务来谈它。王启军总结道，“从长远来看，边缘不会取代公有云，它会作为公有云的一种辅助，成为云的延伸。同时，物联网会变成互联网之上的一个更大的网络，IoT、AI、5G、区块链等关键技术的成熟会促进边缘的快速发展，会帮助人类进入智能时代。”

每天早晨，闹铃一响，窗帘自动拉开，屋外的阳光洒在自动播放早间新闻的床头音箱上。这是一个最简单的智能家居场景，也是最为典型的物联网应用，以家庭为平台，人与物、物与物之间能够互相通信，设备间可以对一个事件进行联动处理，极大方便我们的生活。不过，在资深系统工程师张玉云看来，IoT的万物互联只是第一步，让每个“物”都会学习、能思考，为人类社会产生价值，这才是物联网的价值点。 IoT的第一步：物和物的联接当研究操作系统的工程师碰上IoT会擦出什么火花？张玉云可以给出一个可参考的答案，有着三年操作系统维护，一年容器经验的他，既从事过欧拉操作系统外围包的维护，也定位过系统启动、运行等各层面的问题，这让他养成了一种全局观的思维意识：从系统维度去思考问题，从而更快地理解整个系统。举个例子，智能家居和智慧园区两个场景下的IoT联接，不仅规模数量不同，而且在系统性设计方面，也是各有乾坤。智能家居如果仅仅以家庭为单位，WiFi已经可以提供足够的设备接入能力，以及理想的信号覆盖范围。但是扩展到更大的地域范围，比如智慧园区，就需要系统性设计IoT各设备间的通信以及数据处理功能。在一个园区中，各类传感器采集到的数据，会通过网关设备进行数据清洗，然后再发往云平台完成遥测数据的上报。云平台上的数据，利用大数据等技术做进一步分析处理，让它们产生价值。这其中关键的环节包括数据的采集、上传以及分析。张玉云提到了华为云IoTDA云服务，其提供的物模型概念，可以很轻松地完成设备的抽象建模，定义设备的属性/命令，平台侧无需编码就能理解设备。再配合编解码插件，能够适应更多场景要求。另外，边缘侧可利用华为云提供的SDK完成设备的注册、数据上报等，也很方便。在实际应用中，他也提出了一些产品优化建议，比如IoT上报数据的展示部分是缺失的，需搭配其他云服务进行使用。同时，张玉云和我们分享了一个具体落地的案例，“之前工作中接触过一家传统设备生产厂商，典型的设备覆盖食品加工全过程。基于数字化转型的需求，需要对已有MES系统的数据加以清洗整理后发往平台，再从云端加以存储分析，以便挖掘其中的价值。我们基于华为云提供的云服务，很快为客户提供了解决方案，较好地贴合客户的业务场景。” IoT的第二步：“物”学会思考纯粹的“云—端”模式的物联网架构，存在着实时性、安全性以及成本居高不下的难题，此时如果要让IoT设备端产生的数据可以就近直接分析处理，让“物”学会思考，就需要边缘计算、5G等技术的加入。在张玉云看来，随着地理空间的扩大以及设备规模的增大，搭建局域网使这些设备接入网络的成本也在急剧增加。5G突破了地理位置限制的同时，提供了海量的设备接入能力，理所当然地成为智慧城市等项目网络层的解决方案。随着5G的普及，相信它会大大促进物联网的发展。参与项目的过程中，张玉云发现边缘计算也成为了不少客户关注的香饽饽。边缘计算减少了发往云平台的数据流量、节约成本的同时，使得事件更快地被处理。当前，市面上有不少开源的边缘框架正在帮助开发者完成相关的产品开发，这里就不得不提一嘴华为云开源的KubeEdge。KubeEdge基于kubernetes构建，也是CNCF首个提供云原生智能边缘计算能力的开源项目，它在架构上分为三个部分，其中云端负责云上应用和配置的校验、下发，边缘侧则负责运行边缘应用和管理接入设备，设备端运行各种边缘设备。它能完整的打通边缘计算中云、边、设备协同的场景。张玉云简单描述了它的工作原理，将部署KubeEdge的网关设备理解成node注册给kubernetes平台，所有网关设备又组成一个大的集群，这样的话，对有kubernetes经验的人员来说是零学习成本。张玉云认为，使用kubernetes原生的方式进行管理，还是极具创新精神的。不过，开源产品也存在诸多待改善的地方，需要开源社区的开发者们共同去发现、优化它。张玉云就提到了KubeEdge一些让他难以接受的“功能”，按照kubernetes网络模型，Pods之间无需NAT转换即可互相通讯，由于当前CNI支持的缺失，导致边缘侧Pod中的应用无法直接使用PodIP对接平台。除此之外，如何让边缘侧网关自动发现加入集群，将所有边缘网关组合形成一个集群进行管理，这样做是否有意义，也需要社区进一步讨论使之明朗。结语总而言之，即便当前的IoT工具产品还有待优化，但瑕不掩瑜，在经历了N个loT产品开发后，张玉云最后感慨道，“物联网包含的可能性是其魅力所在，或许，无人驾驶正在离我们越来越近，让我们拭目以待吧。”

12月15日，中科曙光在北京举行“曙光安全可信城市云”发布会。图为曙光云计算集团总裁关宏明介绍相关内容。中科曙光供图中新网北京12月16日电 (记者 张素)“全球云计算市场规模不断增长，我国增长迅猛。”中国科学院信息工程研究所研究员涂碧波援引一份报告指出，从2019年至2023年，中国云计算市场规模年均增长速度将达30%。“国产云计算建设恰逢其时。”涂碧波认为，发展云计算必须坚持“国产＋安全可信”。曙光云计算集团总裁关宏明也有相同观点。他分析称，“全国产云”面临四大挑战，即：核心技术供给风险；技术架构局限、云上能力不能全面提供；技术生态不成熟、云平台集成繁难；云平台不能全面提供信息化建设的需求。他进一步表示，对于“全国产云”，国产和安全是基本功，交付和生态能力才能见真章。关宏明介绍说，15日发布的曙光安全可信城市云全面兼容各类主流架构国产处理器，具备从底层处理器到上层应用的完整技术产品栈，具有安全可信、全栈服务、无忧交付、生态丰富四个核心特点。例如，拥有从基础设施(IaaS)到平台层(PaaS)的全栈技术能力，良好支撑了应用层(SaaS)的各类场景；又如，实现平滑迁移上云，降低了系统改造、软件移植、数据迁移的成本、难度和安全风险。中科曙光总裁助理何牧君表示，曙光方面正在将众多政企用户升级“安全可信城市云”。他们还在各地建设了多个“全国产云”适配中心，已完成主流基础软件和上千个上层应用适配，实现数万个业务应用平滑迁移和稳定运行。涂碧波向记者描绘了理想的安全可信之路，从“被动防御”到“主动防御”再到“动态防御”。“更重要的是要积极建设安全可信的生态。”他说，各方亟需共同构建国产安全可信云技术体系和产品。(完)

中国青年报客户端讯（中青报中青网记者 邱晨辉）“云计算发展白皮书指出，从2019年至2023年，我国云计算市场规模年均增长速度将达30%。云计算走过突飞猛进的十年，也有望迎来下一个黄金十年。”中国科学院信息工程研究所研究员涂碧波在12月15日举行的曙光安全可信城市云发布会上给出这一观点。在涂碧波看来，国内研发机构在国产处理器、操作系统、数据库等核心技术领域已取得一系列突破，构建安全可信的“全国产云”可谓恰逢其时。不管是新基建还是数字化转型，都表明云计算的产业风口已经来临，云计算的生态也正在形成。作为中科院旗下信息科技企业，中科曙光当天推出了安全可信城市云，这是行业内首个全国产云。曙光云计算集团总裁关宏明说，全国产云面临四大挑战，即：核心技术供给风险；技术架构局限、云上能力不能全面提供；技术生态不成熟、云平台集成繁难；云平台不能全面提供信息化建设的需求。在关宏明看来，对于全国产云，国产和安全是基本功，交付和生态能力才能见真章。涂碧波也表示，要积极建设安全可信的生态，亟需各方共同构建国产安全可信云技术体系和产品。来源：中国青年报客户端

大家好，我是一个普普通通的短信平台说起我的工作，相信大家都不陌生无论是注册、登录、还是办理业务短信验证码肯定没少收吧但有时候明明已经发送验证请求了验证码就是不来信号不好？网络出轨？黑客劫持？验证码迷路了么？NO！可能是我压力太大暂时挂了先别喷，我是有苦衷的作为一个短信平台，日均亿级业务流量，每天面对成千上万的手机号和各种业务信息，光是查询就脑壳疼，何况还有那么多业务数据，头都秃了。如果还使用了不太靠谱的数据库，那挂掉也是可能的。当然我不是那种轻易放弃的人，今天就来跟大家分享分享我的抗压小故事你可能知道我们日常业务流量为亿级，但是你知道我们还需要支持按手机号、时间范围精准查询吗？知道我们业务数据需要保留至少180天，甚至更久吗？而且，好巧不巧，霸霸一开始给我用的还是单机数据库，所以经常是一天的数据压下来，我就挂了！可能是看到了我的难处，所以找了一个小伙伴：分库分表小能手-华为云分布式数据库中间件DDM。首先，DDM一来就帮我把业务数据按手机号拆分成了 64个分片（总共4个RDS）；然后，帮我按日期进行分表；TA说因为客户霸霸查询一般是按天查，所以按天分表，可以实现精准查询，嚯，足足分了366个表！对于不需要按时间日期分的表，就帮我开发了库内串行的特性，既能保护数据库，也节省DDM线程提高效率，一举N得呀！考虑霸霸需要清理180天前的数据，DDM决定按分表truncate的方法进行数据清理，说还可以提升数据库性能。对了：truncate是一个能够快速清空数据表内所有数据的SQL语法。经过华为云DDM一顿操作，我不但轻松搞定各种业务高峰，而且持续运行数月，再也未出差错，真是个靠谱的好伙伴！听起来有没有很欣慰？其实，这则小故事，看起来虽然是一个短信平台的“求救”，但实际上，也是千千万万个业务平台的现状。随着时代发展，数据量正成几何式爆炸增长，传统数据库面临着更多挑战，数据问题正成为企业数字化转型拦路虎。率先解决就能站在数据最高点，成为数字时代的赢家。依托华为优秀数据实践验证的方法论、以及丰富的数据管理工具，华为云不但为用户提供一系列高效易用的数据库工具服务，更有全套数据使能解决方案.帮助客户从多角度、多层次、多粒度挖掘数据价值，沉淀行业数据资产，完成数字化转型。看到这里的你，要来一起治理治理你的数据吗？

Hello，各位小伙伴们，SMC2.0 eSDK板块全新上线啦，更清晰的分类、更快速的问题答复、更丰富的活动，统统都来啦。不管你是小白，还是老司机，改版之后的论坛，用好只需要两步走：1.  了解论坛的各个模块，找到合适的位置发帖公告：论坛公告、活动/大赛公告，统统都在这里，关注公告，关注所有的官方重要信息。干货分享：疑难问题、常见问题汇总、专家分享、大牛经验，后续逐步上线。欢迎小伙伴们把自己的干货也分享出来。问题求助：遇到的解决不了的、拿不准的、没有思路的、想咨询别人的，统统都可以发现这里。为了方便大家更快的得到专家回复，问题求助下还细分了APIG、eSDK、SDK、TPOA插件等细分种类，大家在合适的分类下发帖即可。吐槽与建议：管您是产品的使用者还是开发者，如果您有任何关于产品、文档、接口、SDK等等等的吐槽与建议，欢迎大家积极反馈。您的反馈对我们非常宝贵，可能在下个迭代版本就实现了哦。版本资讯：官方发布的版本信息、新功能、变化点，关注版本资讯，版本信息再也不会错过了。 2.  以正确的模板发帖   论坛后面有一整群专家解答大家的问题，所以在发帖，特别是问题反馈或求助时，请一定要按照对应分类下置顶的问题求助模板规范发帖并描述清楚，方便论坛运营小管家将问题传递给对应的专家，光速解决你的问题。欢迎大家发帖、互动，让我们越来越强！