个冲刺阶段的待办事项进行优先排序，编写带有验收标准的简短用户简介，以及进行回顾。许多企业还将评估用户情景并进行其他持续的规划实践。
数字化转型举措往往是该企业改变业务和运营模式的豪赌。这些计划的战略重要性给CIO及其团队带来了更大的压力，他们无法回答将交付什么以及何时交付。
linux内核设计与实现 pdf
敏捷转型顾问、《敏捷宣言》的合著者Jon Kern表示：“领导层有权要求敏捷团队在什么时候交付某样东西，花费多少钱，但团队有权拒绝不切实际的期望。”
这种紧张可能会破坏信任，阻止团队专注于转型目标，并破坏团队长期成功所需的环境。Kern补充道：“我希望我的团队能为让客户微笑、带来价值、并从中获得乐趣而感到开心。”
根据Industrial Logic高级顾问蒂姆·奥廷格的说法，当确定时间表和承诺宏伟目标之间存在矛盾时，领导者需要回到基本问题上来。
敏捷原则定义模糊
除了领导层和团队之间的紧张关系之外，敏捷团队之间和团队内部经常存在次要的紧张关系。
敏捷宣言的合著者Tim Ottinger说：“敏捷的采用通常从引入迭代管理开始，但我们不能指望开发团队本能地了解迭代工程。有一些技能需要学习和掌握，而卓越的技术是成功采用敏捷的关键因素。
今天的敏捷企业的员工、合同工和自由职业者都经历过不同的敏捷框架、方法和工具。决策机构是什么，企业的敏捷原则是什么，团队可以在哪里做决策，标准做法是什么？
“回归基础”对话为企业在支持其数字计划的有效实践敏捷方面经常存在的不足提供了以下几点见解。
没有抓住关键的敏捷原则
99%的敏捷商店没有跨职能的团队，他们也不是自我管理，它就写在宣言的第二页上。”Ottinger说。
允许自我凌驾于商业理性之上，如果我们只是让团队自己决定，几周后，我们可能会看到支票不再兑现了。Agile 必须在企业的环境中工作，无论是财务报告、评估还是预测过程。”Align Agility的总经理Phil Heijkoop说。
陶醉在衡量标准上
《敏捷宣言》的合著者Jim Highsmith说：“有时我们对我们的衡量标准过于执着，有太多的衡量标准，并试图衡量太多无法衡量的东西。”他建议领导者确定一个关注客户价值的指标。
数字化转型计划通常需要多个敏捷团队的协调，因此对原则、团队权限和标准的不一致会导致冲突。CIO和敏捷领导者面临的挑战是为敏捷卓越中心创建一个结构和流程，并根据企业的敏捷原则和标准不断改进。
将变更管理和反馈视为事后考虑
敏捷团队，特别是那些使用CI/CD和其他DevOps实践来实现持续部署的团队，可以很容易地省略数字化转型计划中所需的关键实践。
当敏捷团队部署代码时，他们并实际上没有完成。成功的转型需要变更管理活动，以确保最终用户采用、捕获有意义的利益相关者反馈并审查运营指标。
这些活动是否在敏捷计划的范围内？如果不是这样，这种脱节可能会导致终端用户满意度不佳，并激怒利益相关者。此外，在没有客户反馈的情况下运营的敏捷团队可能会过度设计功能，并错失重新调整优先级的机会。
在这里，Kern提出了一个建议：“告诉人们想一想他们能做的最小的事情，然后做一些稍微不舒服的事情。你总是可以添加更多，但你永远无法回浪费的时间。目标是略显不足，及早获得一些反馈。”
忽略文化方面，或者没有使其与业务目标保持一致
转型需要一种文化变革，让人们超越当今事物的运作方式，挑战假设。敏捷领导者寻求敏捷的心态和文化，但在数字化转型目标的背景下定义这意味着什么应该在CIO 的议程上。
那么，CIO如何定义其企业中的敏捷思维呢？Behers 说：“敏捷的心态是通过我们的行为养成习惯，而这些行为必须在整个企业中普遍存在。”
CIO如何才能知道整个企业正在形成信任和敏捷思维Roth回答说：“敏捷团队和涉众之间的对话转向正确的对话，这不是关于团队的能力，而是关于工作的优先级。”
Highsmith补充说：“敏捷思维的目的是让我们为动荡的未来做好准备。”
对于希望加快数字化转型和改善业务成果的CIO来说，调整灵活的方法和寻求灵活的文化可能会改变游戏规则。以下几点是值得CIO借鉴的行动计划。
要求所有数字化转型计划都有愿景声明；
将敏捷方法应用于迭代计划的整个生命周期，包括规划、交付、变更管理和沟通；
创建一个拥有不断发展的企业原则和标准的敏捷卓越中心；
引导关于敏捷思维和文化在你的企业中应该意味着什么的讨论。
敏捷方法或数字化转型并不是用之四海皆准的方法，其具体形式和细节不尽相同，成功需要CIO承担许多领导责任。
在大力建设算力网络的背景下，随着SDN思潮的深入推进，网络集的部署，负载均衡成为了一种不可或缺的技术，它在云、网、边都起了至关重要的作用。
ECMP
ECMP是一个逐跳的、基于流的负载均衡策略，当路由器发现同一目的地址出现多个最优路径时，会更新路由表，为此目的地址添加多条规则，对应多个下一跳，且可同时利用这些路径转发数据，增加带宽。ECMP算法被多种路由协议支持，例如：OSPF、ISIS、EIGRP和BGP等。在数据中心架构VL2中也提到使用ECMP作为负载均衡算法。
简单来说，ECMP是基于路由层面实现的负载均衡，基于IP层进行负载有许多优点，例如：部署配置简单、可以基于很多协议自身特性实现负载、无需额外配置、提供多种流量调度算法方式、可以基于哈希也可以基于权重和轮询方式。
简单的方式同时意味着存在许多缺陷，具体如下。
可能加剧链路堵塞：因为ECMP不会判断原先链路是否已经堵塞，都会将流量进行负载，这样子会导致原先堵塞的链路更加堵塞。
很多情况下负载效果不好：ECMP无法区分多条网络后的流量空闲情况以及ECMP在流量差距大的情况下负载性能差。
这种基于网络三层的负载方式虽然易于使用和部署，但是无法满足业务层面的使用，无法保持会话。下面介绍几种网络四层以上的负载方式。
LVS负载
Linux虚拟服务器（Linux Virtual Server，LVS），是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的Web请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器。比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务。最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集对用户而言都是透明的。最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS工作模式分为NAT模
式、TUN模式以及DR模式。
与ECMP不同的是LVS是基于会话的四层负载均衡，LVS会基于上下行五元组对不同的流进行会话保持，再结合LVS的长期发展，LVS具有非常多的优势。
NGINX负载
NIGINX除了作为一个高性能的HTTP服务器，同时能够提供反向代理Web服务器的功能，也就意味着部署NG-INX作为一台负载均衡服务器是可行的。当然，业内已经非常广泛的在使用NGINX作为负载均衡服务器、服务集、主备链路等。
NGINX和LVS类似，都是基于四层以上的负载均衡，能够保持会话。同时因为NGINX工作在网络七层，相比LVS负载，NGINX对网络的依赖会更小。
相比LVS负载均衡，NGINX具有如下优势。
对网络依赖小：只要网络能通就能做负载，不像LVS 部分模式需要特定的网络环境。
安装简单，配置部署快。
NIGINX负载可以检测到服务器内部故障：简单来说，上传文件时发生故障，NIGINX会自动将上传切到另一台负载设备处理，LVS无法如此使用。
同样的，NGINX也存在一些缺点，例如：缺少双机热备方案，多数情况下单机部署存在一定风险；功能调整度高，变相导致它的维护成本和难度高于LVS。
思考和探究
综合以上几种常见的负载技术的优缺点不难发现各有各的好处。然而在实际使用过程中，这几种方式都很难满足高性能跨网负载，即在做FULL-NAT的前提下实现跨城域网的负载。简单来说，就是在实验多节点云化部署时，这些方案都存在一定的性能贫瘠。
基于此，笔者发现Cisco开源的VPP项目提供了一种高性能负载均衡器的方式，基于DPDK收发包，VPP的高性能处理，经过二次开发可以实现跨网高性能负载，目前已经取得一定成效。
未来，智慧家庭运营中心会在实现高性能跨网负载均衡器上进行更多的研究，欢迎更多的开发架构人员投入到高性能跨网负载均衡器的功能开发和场景探究之中来。
■郝华灿

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。