隶属于中国技术先锋年度评选，旨在挖掘并鼓励行业先锋企业和具有影响力的技术品牌。在重重评选下，网易凭借
2021 年，网易有道技术团队始终保持着高效产出，分享各类产品经验，并曾多次组织或参与技术大会、开发者大赛、技术沙龙等活动，共输出高质量技术博客60+篇。
作为一家以成就学习者“高效学习”为使命的智能学习公司，网易有道一直秉持着高效学习从有道开始的理念，时刻注重智能科技产品更新迭代，致力于让每一位学习者不断地提升自己的同时，还能收获最好的产品体验。
网易有道依托于强大的互联网AI等技术手段，围绕学习场景，打造一系列深受用户喜欢的学习产品和服务。包括有道词典、有道词典笔、有道智能学习终端等多样化智能学习工具，以及素质教育、学科教育和终身教育等覆盖全年龄段的在线课程平台，真正做到了从用户角度出发，以用户体验为先。
未来，网易有道技术团队将继续加强科技生态建设，以领先技术打造更多高质量科技产品，保持高质量技术内容输出，和开发者共同成长。
本文为网易有道企业发展高级效能项目经理张浩然《研发效能实践助力互联网行业项目管理“行之有效”》的演讲内容，围绕研发效能的实践和项目管理两个主题展开。
我写分享PPT的时候，起初想的是针对于互联网行业的项目管理。但现在不止是互联网，传统行业也在做数字化转型。所以，这个项目管理是全行业都可以一起探讨的。我之前做研发，后面主要做项目管理，过程中做过一段时间的产品管理。目前主要在网易有道企业发展部，做整个研发效能的推广和项目管理的提升。
目前我们处于一个乌卡时代，不光是互联网，传统行业也处于这个时代。任何一个时代到来，都不会抛弃任何一个人，这个时代有哪些特殊性？——易变，不确定性，复杂性和模糊性。
所谓易变，就是每次迭发要快，因为市场变化很快，我们其实也不确定产品的下一步方向在哪，用户有哪些新的诉求；
而复杂性是说现在产品的形态、架构很多，不能像以前一样用一套标准的解决方案满足各个客户的需求。因为客户也学聪明了，我们需要去应对一些更复杂且不明确的诉求。模糊性更好理解，一些大厂如阿里是电商出身，百度是搜索引擎，但是越往后，每一块垂直领域市场趋于饱和，大家在各自的边界越来越模糊。所以，我们要不断地让我们的MVP产品快速推出，在乌卡时代取得先机。
项目管理，能在这个时代帮助企业降本增效，快速验证。但是我们在管理整个软件研发团队时，多少会遇到一些问题或困扰。比如现在有一个想法需要做，我们组建了一个团队，快速地做研发迭代。为了赶进度，大家还要加班。很辛苦，但真正交付产品的时候，还是会出现延期交付。
在研发过程中，为了赶进度多少会产生一些质量问题。在整个过程中，为了弥补延期和质量差的问题，会去抓人效，抓的过程中又容易引起团队里的一些反驳，导致士气低落，如果在上线以后，我们的产品再不被市场接受，整个团队久而久之士气更加低落。
有人说我是一个经验很丰富的项目管理或者产品经理，或者技术领导，我在整个排期或者任务分配的过程中都没有问题。那我们如果有跨团队协作，比如说网易有一个A团队，很重视测试环节，在测试环节分为好几轮，并且用网易易测平台去扫描检查代码。另外一个B团队，业务形态没有那么复杂，只是简单地走完测试流程就OK了，过程中没有很多自动化工具，可能还在用XMIND等思维导图写用例，线下做管理。但如果B团队的伙伴去支援A团队的项目，对于A团队的工具、流程都不熟悉，怎么能够快速让B团队融入A团队，快速产出，这都会成为阻碍团队高效产出的问题障碍。
我们现在的挑战是会遇到交付过程慢的问题。因为我们的产品线越多，需要交付的产品就越多。在不同的过程中，针对于某一个产品有一些新的需求，需求过来以后就会建立很多版本分支。这个过程中，比如我正在开发A版本的过程插入了新需求，要新开B版本，从A切到B的时候其实是对开发有影响的。同时，比如项目前期，大家都在做一些调研，然后再开发，这个阶段测试人员在等待开发完成才能进入测试，等待时间过于长，导致整个交付比较慢。质量差也是一个问题，研发之前没有测试的意识，只写好自己的代码就提交了，可能有些为了赶进度都不自测。排期不合理，大家有可能经常会遇到这种问题。排期就是把研发的时间排出来，把剩下的时间压缩为测试时间，测试很大的一部分功能模块也就几天，三四天，小功能的话半天就得赶紧测完要上线，所以为了去赶进度，牺牲了质量。
协作难这个问题，有多个团队缺少标准的流程工具。在整个过程中一是出现人员的协作、项目切换难；二是遇到一些问题的话，可能会出现扯皮；最后，就是少度量。如果没有度量的话肯定是不行的，项目经理包括管理层不知道整个团队目前的现状，包括技术领导也肯定没有办法合理地做任务分配。整个过程度量的缺失，就没有办法去衡量大家的绩效。现在在推行OKR，其实也是有度量的，也就是KR的达成程度怎么样。这些常见问题时压在团队身上的几座大山。
在这个过程中，会形成马太效应。每次质量差，上线以后有问题，运维工程师变成“背锅侠”；测试需要针对现有的问题尽快去验证，追着开发去修复，成了“追责侠”；最后我们的开发，只能加班加点去干，成了“加班侠”。这就是互联网时代“三侠”，工作很累，但是结果不理想，每天还吵得不得了
通过访谈或者观察的方式看目前是什么问题。访谈是一部分，观察也一定要有。因为整个研发团队在工作过程中是不希望被打扰的，如果打扰到他，一是可能配合力度不够，二是在访谈过程中可能会有一些答案是得不到的，所以在团队人员时间紧张的条件下，需要通过观察来发现问题。大家如果有时间，可以邀请去做共创，或者是内部的共创。同时可以把好的案例分享给我们团队，看看他们的接受程度。
需求的话，一开始没有需求管理工具，大家靠书面记录，效率比较低，而且需求更新后，下游是不可知的。没有做需求变更管理就会导致快上线验收的时候才发现，开发的一些功能和实际想要的完全不一样，或者差异很大，这对团队是一个致命打击。包括开发构建、测试等环节也或多或少会有问题，针对这些问题我们做分析和定位，包括人、流程、工具各个方面。
首先从业务到运维多个环节对单点的工具、流程进行一些优化，终极目标是建立一套能够从业务需求到上线发布的端到端，能够支持整个研发过程，快速高质量和持续发布的解决方案。
一是要快速，二是质量要高，三是持续交付。不能是一次快，或者是一次质量好，要持续达到这个目标。
前期会通过一些流程规范，针对需求做基于流程的驱动。我们搭建了一套标准工作流，在这个工作流中基于不同的团队建分支流程，尽量落在这套标准的流程上。我们希望通过一些流程，来推动整个产研的过程，不管是通过卡片还是通过自动化的工具，或者说转化过程，通过工具去驱动，把这个数据沉淀下来。同时，在代码级别和测试级别，自己做了一些封装，有些是自己去做的。CICD方面后面讲，没有完全做成自建的，会做前端的封装。我们的产研团队的用户看到用的是一套平台，在一套平台上完全整个需求到上线的过程，对他们的感知比较友好。
CI/CD的核心流程，用tekton引擎去做的。通过一些pipeline组合，去完成整个流程管理，通过task的文件去做整个pod的调度，实现整个过程持续的流水线。
基于这个层面，已经从产品设计到需求、代码去做一些构建，发到对应的环境，去做自动化的测试，完全去实现全链路的拉通，包括上线以后有数据看板。有了这一套全链路的工具平台，就可以更好地去支撑我们的敏捷开发模式，最后一步卡在运维。
这样的话，通过这套平台可以得到一个需求，跑完以后快速上线，上线以后快速地验证。验证完以后，是否OK，具不具备发布条件，当期发布目前已经是OK的。
把整个研发过程拉通，通过自建去做。我们的项目管理应该怎么去做一些切入？和研发效能做结合。首先，在项目管理方式上做一些改进，在传统的项目管理中有一个传统铁三角的概念。项目管理管理上，会针对项目的范围、时间、成本传统的软件行业，更注重这三块。比如我是乙方，给甲方签了合同，交付一些平台或者系统，在这个过程中会有严格的范围定位。我们的立项时间分几个月去交付，一期、二期、三期包括我们的时间、成本，甲乙方对接的时候更需要做成本控制。项目管理更多的是在这三个层面触发，然后在过程中去做过程管理。但是这种模式，其实是需要做一些改进的。因为现在是一个互联网时代，乌卡时代，大家不可能说在一开始就确定要什么，给你多长时间，给你多少预算做出来，所以需要做一个转变，这就是敏捷三角的概念.
范围、时间和成本这三块也要看，只是比重没有那么高，而是作为整个项目管理的约束条件，也就是说我们要在有限的范围、时间、成本里面寻求最有价值的部分。
而在这个过程中，可以通过一些工具、流程把质量逐步提升。通过敏捷三角的项目管理方式，每次去交付最有价值，而不是全量的范围，可以基于价值每次去拆分最小的单元颗粒度做mvp，如果价值有变化，快速地做调整。
其次，项目管理过程中要做一些流程改进。从项目管理角度来说，原来是一个线性的流程，一般有了项目以后，要去做立项，做可研论证，可行性研究，做整个产品的设计，UE、UI的设计，研发、测试、上线，整个过程中都是线型的。存在一个问题，如果产品的需求PRD没有画好，UE是不是不能做？开发是不是也不能做？
于是我们改进了流程，减少了它的前置时间。PRD没有完全写好，但是用这种用户故事的形式，先给出整个用户故事的全貌。通过最终要做成什么样，拆出来最有价值的部分，后面UE和开发就可以先做这个部分的需求。最有价值的部分做完以后，可以实现优先级排序里第二有价值的功能。相当于把整个功能拆解完以后，后续的各个流程都可以直接接入。
另外根据项目管理计划，要做管理肯定要有一个度量体系，不然无法知道整个研发团队的效率点，或者工作饱和的情况。允许大家存在一定的“摸鱼”，但是要适可而止。有一些“摸鱼明显不合理时，就需要做度量。
短期度量是第一步上来要做的，因为没有全流程的链路平台统计，都是基于过程的度量，只能单点收集需求、开发、测试、运维各个过程的数据。项目经理比较累，需要通过excel表，手动地去各个平台去扒，或者去其他的一些地方去问，这是比较难的。但是有了这个度量体系，基本上可以以此驱动。哪个数据现在大家看得比较重要，或者收集过程比较痛苦，就可以逐步做一些改进。
单点的数据有了，第二步就要关注交付的目标。比如这次需要交付5个还是交付10个的故事，这个过程基于整体的目标去做，在过程中会通过一些人员的效率，比如说周期，人均的效率包括缺陷的修复时间，通过整个迭代去看，而不是通过某个需求去看。另外，迭代发布的话，看一下发布频率或者发布前置时间。发布前可能涉及到环节没有准备好，因为遇到过一些情况，大家一开始着急开发，等到快上线的时候，给测试发申请，或者又在等一个机器配置什么的，很阻碍时间。发布时间就会拉得很长，导致最终整个迭代的版本上线就会很长。质量是会通过一些整个过程和迭代里面的冒烟驳回率、缺陷密度和缺陷漏测率和其他指标去做。
第三步，基于价值的度量。有了目标，但是这个目标只是说实现产品价值中间的过程，最终还是要实现有价值。以价值为导向，层层去过滤整个环节，单点去做还是通过迭代去做，层层拆解，逐步的消除。以价值的交付为导向，通过可视化的看法或者仪表盘逐步分解，分析，提高整个研发效能的效率和质量。
这样的结合路径会基于产品用户和市场三个层面做整体权衡，输出这次最有价值的点，相当于有一套自己的价值评估体系，会融入到整个产研体系。在产研过程中会去做一些需求规划、版本管理、时间盒，项目经理可以更有效地做过程把控。
我们的目标是希望通过整套能效平台，可以快速地探索和分析业务，形成一个MVP，快速实现MVP的上线.研发效能的未来展望
要关注数据是否有效，合理性怎么样，够不够丰富，要做这块的数据源整合，通过分析增加监控指标。这个深度需要更加合理，更加促进研发团队高效工作，不破坏团队氛围。
虽然我们公司也有AI的能力，AI的团队，但是AI要基于大数据去做。只有数据很丰富同时合理性高时，去做AIOps才会合理有效。因为只有对正确合理的数据进行分析，检测出的问题以及自动修复才是合理有意义的。用不合理的数据去做AI，方向就错了。
有道纵横是网易有道旗下专为4-8岁孩子量身打造的在线年启动，自研了全国首部在线交互式围棋动漫课程，从孩子的理解力和喜好出发，采用直播互动的课程形式将围棋知识变得简单有趣、易懂好学，帮助孩子掌握围棋的各类规则和技巧。不仅如此，课后还设有AI对弈功能，能够智能识别孩子的段位水平匹配对局练习，从根源培养孩子的思维习惯。每局对弈结束后的智能分析，会从大局观、计算力、稳定性、战斗和棋型五方面进行全方位分析，帮助孩子在复盘中进步。
Google旗下Deepmind提出的AlphaGo、AlphaGo Zero、AlphaZero系列算法展示了深度强化学习在棋类领域超凡的能力。2016年AlphaGo横空出世击败欧洲围棋冠军樊麾二段，2017年以4：1击败韩国围棋职业九段，14个世界冠军得主李世石，2018年无师自通的AlphaGo Zero以3：0击败最年轻的六冠王柯洁九段。至此以后再无人质疑AI在围棋领域的霸主地位，同时引发了职业棋手学习AI招法的热潮。在职业围棋赛场上，时常出现“狗招”，学习、研究AI招法的背后的逻辑，已是职业棋手的必修课。
Github上已经有了Leela Zero、KataGo等基于AlphaZero系列算法的优秀围棋AI开源项目，它们的主要目标是提升AI的棋力，目前上述围棋AI的棋力已远超人类职业棋手。然而当强AI应用在少儿围棋教学时，出现了“水土不服”的现象，比如：
• AI实在是太强了，人很难在与AI对弈的过程中体会到“旗鼓相当”的感觉，这极易引起用户的挫败感。
• AI的学习路径与相径庭，一些在人早期围棋学习阶段就可以掌握的知识（如征子），AI在训练后期才掌握。
技术团队永远都说AI老师特别有用，可以解决个性化教学的问题，可以因材施教；老师背景的团队往往觉得AI老师就是洪水猛兽，既没有用而且骗了很多VC的钱。
纵横项目当中做了比较多的AI老师的思考和实践。我们看法是，大众对于AI的认知，其实对于产品团队来说是个双刃剑，只有认识到双刃剑的作用才能做出正确的设计。
什么是双刃剑？一方面AI是一个非常好的营销抓手；另外一方面，用户不懂做产品，团队必须去自己寻找真正的AI价值点。如果你听用户对哪个东西兴奋就做哪个，最后往往掉坑里了。
在AI场景下，我们思考了非常久。首先想到AlphaGo，不管多牛都下得过你，但这么和用户讲显然不可能，所以本身对弈的难度和棋力不是教学当中AI的指标，而是如何降低难度，怎么能够灵活的调整难度。
所以，第一，我们团队花了大量功夫做难度可控的、棋力可控的围棋AI；第二，可控棋力的AI和复盘能力；第三，我们推的是学员和学员、学员和老师之间的对弈，强调人人对弈而不是人机对弈，人机对弈只是找不到人对弈时候的补充手段。
通过这样的手段，我们实现了自主研发的围棋AI，教学过程当中能够代替掉人的部分工作，提高了团队的生产效率。
一些其他方案在实现人机对弈系统时，一般使用AI训练过程早期的模型，然后使用模型的top-n输出，随机抽样进行落子行为，避免AI落子过于单一。
这种方案除了易于想到之外没有其他优点，由于早期模型训练量不大，采用top-n的采样方导致AI的招式没有条理，用户很容易诱导出这种落子逻辑的漏洞（如征子）。其次，在对弈过程中，AI模型和落子策略是固定的，但我们在实践中发现，AI对于围棋中的布局、中盘、收官等阶段的招法学习速度并不相同，AI对布局的掌握速度远远超出中盘、收官，使用相同的模型和策略会导致AI在整盘棋的表现差异极大。再者，AI的自对弈训练中，没有定式的概念（定式是围棋高手在某些局部的经验总结，用户学习定式走法可以快速提升棋力），低水平的AI很难在局部中下出最优解，而人可以通过学习高手的棋谱快速掌握局部最佳下法，即使人的水平并没有达到提出该定式的围棋高手水平。
• 在不同手数阶段，结合胜率和目差信息，调用不用的AI模型。保证AI在不同阶段的水平表现相近。
复盘指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。一般用以自学，或请高手给予指导分析。下围棋的高手都有复盘的习惯。复盘就是每次博弈结束以后，双方棋手把刚才的对局再重复一遍，这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞，是提高自己水平的好方法。在有道纵横产品中，AI承担了复盘老师的角色。
一些其他方案中，AI复盘主要是展示整局棋的胜率或目差曲线、AI的推荐变化图、以及一些基础的统计数据，这些内容更适合专业的用户，专业用户的需求在于快速定位自己下的不好的棋，然后根据AI提供的变化图等推理AI的落子逻辑，此类用户仅根据围棋AI引擎的原始数据就可以完成自我学习。
但是当用户群体定位到少儿时，上述的解决方案效果就会大打折扣，少儿用户很难理解统计数据背后的意义，同时对AI提供的变化图的逻辑缺乏分析能力，甚至注意力很难集中在变化图上，仅关注整局棋的胜率、目差的变化。此外，其他方案采用的复盘使用的GPU资源消耗很大，有的用户甚至需要半天时间才能拿到对局的复盘结果。
• 性能优化，在少儿用户的使用场景中，用户并不需要高算力AI产生的复盘结果，我们指定了根据局面的复杂程度分配算力的方案。
目前围棋AI的技术主要集中于提升AI水平上，这固然为专业用户自我训练提供了极大的便利，但由于高水平AI背后的行棋逻辑较为高深，当围棋AI为少儿用户提供服务时，少儿用户很难直接从高水平AI获取知识。
接下来我们希望可以在人机对弈场景中，为用户提供水平更合适、逻辑更连贯的AI陪练；在复盘场景中，为用户提供更清晰易懂的复盘报告。
本次以Redis为范例，阐述了有道基础架构团队在基础设施容器化道路上的实践，主要将从声明式管理，Operator工作原理，容器编排，主从模式，集群模式，高可用策略，集群扩缩容等方面展开。
传统物理机部署中间件，需要运维人员手动搭建，启动时间较长，也不利于后期维护，无法满足业务快速发展的需求。
云原生相较于传统IT，可以助力业务平滑迁移、快速开发、稳定运维，大幅降低技术成本，节约硬件资源。
云原生中间件是指依托容器化、服务网格、微服务、Serverless等技术，构建可扩展的基础设施，持续交付用于生产系统的基础软件，在功能不变的前提下，提高了应用的可用性与稳定性。
在这种大趋势下，有道基础架构团队开始了云原生中间件的实践，除了本文介绍的 Redis，还包括 Elasticsearch、ZooKeeper 等。
所谓“声明式”, 指的就是我们只需要提交一个定义好的 API 对象来“声明”我所期望的状态是什么样子，Kubernetes中的资源对象可在无外界干扰的情况下，完成当前状态到期望状态的转换，这个过程就是Reconcile过程。例如，我们通过yaml创建了一个Deployment ,Kubernetes将“自动的”根据yaml中的配置，为其创建好Pod，并拉取指定存储卷进行挂载，以及其他一系列复杂要求。
因此，我们的Redis集群是否可以使用一个类似的服务去完成这个过程呢？即我们需要定义这样的对象，定义服务Reconcile的过程。Kubernetes的Operator刚好可以满足这个需求，可以简单的理解Operator由资源定义和资源构成，在充分解读集群和Operator的关系后，我们将整体架构图设计如下
哨兵模式中Redis服务用一套哨兵集群，使用StatefulSet部署，持久化配置文件。Redis server也采用 StatefulSet部署, 哨兵模式的实例为一主多从。
Redis的资源定义在ETCD中存储一份即可，我们只需要预先提交自定义资源的 yaml配置。
Operator 无需任何修改，即可从 Kubernetes 核心中获得许多内置的自动化功能，如使用 Kubernetes 自动化部署和运行工作负载， 甚至可以自动化 Kubernetes 自身。
Kubernetes 的 Operator 模式可在不修改 Kubernetes 自身的代码基础上，通过关联到一个以上的定制资源，即可以扩展集群的行为。Operator 是 Kubernetes API 的客户端，核心功能是充当定制资源的。
用户创建一个CRD自定义资源，ApiServer把CRD转发给webhook，webhook 进行缺省值配置 验证配置和修改配置，webhook处理完成后的的配置会存入ETCD中 ，返回给用户是否创建成功信息。Controller 会监测到CRD，按照预先写的业务逻辑，处理这个CRD，比如创建Pod、处理新节点与旧集群关系等，保证运行的状态与期望的一致。
• limit(资源限制)：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。
Redis 基本不会滥用 cpu，因此配置1-2个核即可。内存根据具体业务使用分配，考虑到部分场景下会fork较多的内存，例如 aof 频繁刷写，aof 重写过程中，Redis 主程序称依旧可以接收写操作，这时会采用 copy on write (写时复制)的方法操作内存数据，若业务使用特点为“写多读少”，那么刷写期间将产生大量的内存拷贝，从而导致 OOM，服务重启。
一个有效的解决方式为减少刷写次数，将刷写操作放在夜间低流量时段进行。减少刷写次数的方法为适当增加auto-aof-rewrite-min-size的大小，可配置使用内存的5倍甚至更大的最小刷写量；其次可以主动触发刷写，判断内存使用达到的配额两倍时进行刷写，实际部署时一般也会预留50%的内存防止OOM。
：依据数据是否需要持久化或是否需要唯一标识区分服务为无状态和有状态的服务，Redis集群需要明确主从、分片标识，大部分场景也需要数据持久化，Kubernetes使用StatefulSet来满足这一类需求。StatefulSet的顺序部署、逆序自动滚动更新更能提高Redis集群的可用性。
：Redis Server 启动时需要一些配置文件，里面涉及到用户名和密码，我们使用 Configmap 和 Secret 来存储的。Configmap 是 Kubernetes的Api 对象，常用于存储小于1MB的非机密键值对。而 Secret 可以用于存储包含敏感信息的密码、令牌、密钥等数据的对象。
所有实例共用一组哨兵将进一步提高实例启动速度，并在一定程度上可提高硬件资源利用率，实测单组哨兵可轻松应对百规模的主从集群。
通过在传统Redis Cluster架构中引入代理功能，实现动态路由分发，并基于Kubernetes原生动态扩缩容特性，更易应对突发流量，合理分配使用资源。
• 对于操作多个Key的命令，如果这些Key是储存在不同的数据分片，Proxy会将命令拆分成多个命令分别发送给对应的分片。
（1）处理失败节点, 对部分节点重启后的无效ip、状态为noaddr的僵尸节点进行forget操作；
（2）处理不可信节点 (所有handshake状态的节点)，发生于某一个节点被移除（由forget node触发），但试图加入集群时，即该Pod在Operator角度下存在，但实际集群节点并不需要该节点，处理方式为删掉这个Pod，并再次做forget操作直到Pod被删除。
Redis部署最小资源对象为Pod，Pod是Kubernetes创建或部署的最小/最简单的基本单位。
当启动出错，例如出现“CrashLoopBackOff”时，Kubernetes将自动在该节点上重启该Pod,当出现物理节点故障时，Kubernetes将自动在其他节点上重新拉起一个。
节点纵向扩容时，使用StatefulSet的滚动升级机制，Kubernetes将逆序重启更新每个Pod，提高了服务的可用性。
Kubernetes本身不处理Redis 多个Pod组建的集群之间的部署关系，但提供了部署策略，为保证特定场景下的高可用，如因物理节点导致所有Redis节点均宕机，CRD在设计中加入了亲和与反亲和字段。
：因物理节点驱逐、节点重启、进程异常结束等导致的Redis主节点宕机情况，哨兵会进行切主操作，然后Kubernetes会在可用物理节点上重新拉起一个Pod。
：哨兵模式的Redis集群未开启读写分离，从节点宕机对服务无影响，后续Kubernetes会重启拉起一个Pod，Operator会将该Pod设置为新主节点的从节点。
：主从模式下配置了三个哨兵用于集群选主操作，哨兵集群的每一个节点会定时对 Redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。当节点被一个 Sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。
如果客观下线的 Redis 节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。
纵向扩缩容主要指Pod的CPU、内存资源的调整，基于Kubernetes的特性，只需修改实例对应的spec字段，Operator的调和机制将持续监测参数变化，并对实例做出调整 。当修改cpu 、内存等参数时，Operator同步更新StatefulSet的limit、request信息，Kubernetes将逆序滚动更新Pod，滚动更新时，若停掉的是主节点，主节点的preStop功能会先通知哨兵或者集群进行数据保存，然后做主从切换操作，从而将服务的影响降至最低。更新后的主从关系建立以及哨兵monitor主节点功能也由Operator一并处理，全过程对客户端无感知。主从版、集群版在该场景下均支持秒级断闪。
横向扩缩容主要指副本数或节点数的调整，得益于 Kubernetes 的声明式 API，可以通过更改声明的资源规模对集群进行无损弹性扩容和缩容。
Redis Server扩容操作时，主从版本中Operator将获取新节点ip, 新启动节点将在下一轮调和时触发slaveof 主节点操作，且同步过程中，哨兵不会将该节点选为主节点。集群版本中Operator将在同步节点信息后进行分片迁移，保证所有节点上的Slots尽可能均匀分布。
Redis Server缩容操作时，主从版本中Operator将逆序销毁Pod，销毁时会先询问哨兵，自己是否为主节点，若为主节点则进行先failover操作再退出。集群版本中Operator中会先进行分片迁移，再对该节点做删除操作。
代理的扩缩容，更易实现，根据流量波峰波谷规律，可手动定期在波峰到来时对 Proxy 进行扩容，波峰过后对 Proxy 进行缩容；也可根据HPA实现动态扩缩容，HPA也是Kubernetes的一种资源，可以依据Kubernetes 的Metrics API的数据，实现基于CPU使用率、内存使用率、流量的动态扩缩容。
有道架构团队最终以云平台的形式提供中间件能力，用户无需关注基础设施的资源调度与运维，重点关注具体业务场景，助力业务增长。未来，将进一步围绕Redis实例动态扩缩容、故障分析诊断、在线迁移、混合部署等内容展开探索。
\Kubernetes 是一个容器编排系统，可以自动化容器应用的部署、扩展和管理。Kubernetes 提供了一些基础特性：
：部署更快，集群建立无需人工干预。容器部署后可保证每个的Redis节点服务正常，节点启动后将由Operator持续监测调和Redis集群状态，包括主从关系、集群关系、哨兵监控、故障转移等。
：如果所有服务都用同一个集群，修改了Redis集群配置的话，很可能会影响到其他的服务。但如果你是每个系立用一个Redis群的话，彼此之间互不影响，也不会出现某一个应用不小心把集群给打挂了，然后造成连锁反应的情况。
：容器部署可根据limit和request限制实例的cpu和内存，也可以进行扩缩容操作，扩容后的故障恢复由Operator处理。
：基于Operator对CRD资源的持续调和，可在Operator的Controller中为每个Redis实例进行状态维护，因此，节点调整后带来的主副关系建立、集群Slots迁移等均可自动完成。
自 2017 年 10 月推出有道翻译蛋开始，网易有道已先后推出了二十余款智能学习硬件产品，包括有道翻译王、有道口袋打印机、有道超级词典、有道词典笔、有道听力宝等。
为了给用户带来更好的体验，有道 AI 团队选取了多种真人发音素材，从来自公司内部、真实用户和 native speakers 等人群中选取足够大的样本发放调查问卷，从
和韵律特征, 其中音素序列决定 TTS 是否正确读对了文本；韵律特征决定 TTS 的停顿位置、自然度等，这也是有道 TTS 技术能够实现接近真人发音和正确朗读多音词的关键所在。传统的文本分析模块会单独建模每个任务，并且串行处理效率较低，这种做法在嵌入式场景中难以实现性能和质量的平衡，多个任务分离也会提高系统的维护成本。
相比于传统方案，有道 AI 团队基于 BERT 预训练模型进行了多任务建模，将多个任务进行统一建模，大大提高了效率。
：在资源收集阶段，借助有道独有教研资源，搜集整理多音字表，结合词性、词义等细化多音字模型标签，使得建模更高效；在中文古诗词、文言文发音上，通过 ssml 技术将词典笔海量权威发音词典资源应用到TTS 发音中；
：在模型实验阶段，前端包含有多音字、韵律预测、分词、词性预测等这些任务，通过构建bert多任务模型，联合预测多音字、韵律、分词、词性任务，多个任务之互相促进不仅了提升多音字模型和韵律模型的准确率，同时也节省了参数量；最后通过蒸馏技术，小参数量多任务模型在保证质量的同时，也达到嵌入式性能要求；
:在系统集成阶段，工程化团队通过自研bert pipeline技术，更进一步优化了内存和推理时间；
：比如 Tacotron、Tacotron2，优点是高自然度，缺点是性能较差；基于 attention 的自回归声学模型难以建模长语音，更容易出现丢字、重复的现象。
：比如Fastspeech、Fastspeech2，优点是并行生成声学特征，性能好，对长句建模足够鲁棒；缺点是韵律建模略差于自回归声学模型。综合质量和性能，有道 AI 团队最终选择了
问题进行了工程上的优化，进一步改善了系统整体的实时率。另外，还对模型进行了量化，降低了模型的内存。
。声码器模型的建模能力不足，会直接导致合成语音产生底噪或者电音。但如果仅仅只是单纯地加大模型的参数，则会影响系统的推理速度。
。声码器的计算量在语音合成的整个框架中占比较大。要在嵌入式场景中合成高质量的语音，需要一个足够大、建模能力足够强的声码器模型。但由于设备芯片的算力弱、内存小，大的声码器会导致体验延时明显上升。从用户的角度出发，延时过长，用户等待时间过久，自然不会有好的体验效果。
为了解决以上难题，通过大量实验和综合比对，最终有道 AI 团队选择了基于 GAN 方案的声码器。
首先是针对不同场景使用不同的模型配置，有道 AI 团队对 GAN 声码器中的生成器模块进行了参数的细致调整，让它能够成功应用在嵌入式场景下，不同于传统参数声码器的机械感与模糊感，基于 GAN 的神经网络声码器可以合成高自然度、高清晰度的音频，
如何更快地、更稳定地在有限资源下提供高质量的语音合成技术是有道 AI 团队的目标和关注的重点。
目前，有道 TTS 语音合成技术已应用在许多内部和外部的在线场景和嵌入式场景，并表现出了相对传统方案更加稳定、更加鲁棒的合成效果。
：有道技术团队助手：ydtech01 /邮箱：相信了解算法同学经常会说动态规划太难了，看到题目完全不知从何下手，或者是说“一看题解就会，一看题目就废”这样的一个状态。本质上是由于学习动态规划的时候，学习方法不对，最终导致南辕北辙，没有掌握其中精髓。而动态规划与递推算法又有着暧昧不清的关系，我们选择先从递推算法入手，一步一步揭开动态规划的神秘面纱。
发表评论