迁移时要避免的常见错误

对于能够迁移数千个应用程序的企业来说，这是保持竞争力的必然部分。弄清楚如何实现成功的迁移是很可怕的，所以让我们深入了解要避免的陷阱。

COVID-19 造成了技术人才短缺和对加速技术时间表的需求增加。许多公司开始面临“ 红皇后”效应，公司不得不重新定义他们在市场上竞争的方式和地点，以确保它们保持相关性。今天，仍然自满的企业将获得令人痛苦的劣势和永久的追赶周期。从现有技术迁移到更具响应性和成本效益的解决方案是任何企业转型的重要组成部分；然而，对于毫无准备的人来说，它可能充满陷阱。

根据波士顿咨询集团 2020 年的一项研究，该研究包括 70 家公司的 825 名高管，涉及 895 次数字化转型，只有 30% 的转型实现了转型目标。

这些不是激发信心的数字。幸运的是，像 Stark & Wayne 这样的企业已经努力实现多个企业迁移，这样其他人就可以避免它们。 Stark & Wayne 是迁移企业级基础架构的专家。过去的项目包括管理 45,000 个应用程序实例的Cloud Foundry Foundation部署。

记录绩效基线

是委托！每家公司都需要更好的绩效，但许多公司缺乏基准绩效指标或衡量更好绩效意味着什么的方法。性能与最终用户体验有关吗？性能是否基于扩大和缩小工作负载以减少消耗？是否通过缩短部署或升级时间来衡量性能？一旦确定了如何衡量性能，您就可以将其与您的应用程序、客户和业务联系起来。

这将使您能够评估应用程序在迁移期间和迁移后是否表现不佳。它还有助于管理重大变化期间的看法，并有助于量化成功。您需要将迁移前和迁移后的平台与类似的工作负载进行比较。您衡量的内容取决于业务需求，但一些通用的衡量标准是：

• 组件运行时间
• 应用程序响应时间
• 应用程序总体执行时间
• 测试应用程序以验证组件连接性和服务可访问性
• API 指标（页面负载、内存利用率、CPU、服务器性能）
• 日志输出负载
• 随时间变化的事件报告负载
• 自动化（并将自动化视为一等公民，因为它将提高整体性能）
• 迁移和任务自动化导致的运营成本变化
• 使用为您的环境建模的应用程序类型进行测试。

好的仪表板：你不能迁移你找不到的东西

大多数组织都知道他们现在支持什么，但需要确定迁移后他们想要支持什么。知道应用程序实例的数量很容易，因为您的供应商可能会根据此指标向您收费。尽管如此，您还需要了解应用程序的数量、哪些团队支持应用程序、应用程序具有哪些相互依赖关系以及每个应用程序正在使用哪些类型的服务。识别这些变量将有助于确定如何迁移和支持新环境。

在确定每个应用程序的所有者时，必须确定哪些拥有自动化测试脚本来验证应用程序是否正常工作。理想情况下，每个应用程序都有自动化测试脚本，但至少，您需要拥有应用程序所有者的映射。此外，您将需要寻找未使用和未维护的应用程序。当应用程序需要在迁移之前删除或修复时，您要做的最后一件事是迁移非功能性应用程序（我们已经看到这种情况发生）。很多时候，您会发现应用程序所有者的主映射不存在，这会在迁移期间和迁移后引发问题。

因此，重点是“盘点、盘点、盘点”，因为许多公司没有一个中心位置来编目谁拥有每个应用程序、每个应用程序有什么或做什么，以及该应用程序的业务影响是什么。快速查询和查找相关信息的能力对于运营、效率和业务决策至关重要。

从哪儿开始？首先，回答更广泛的问题：

• 您在哪些地区跑步，为什么？
• 每个区域都在运行哪些应用程序？
• 每个应用程序在每个区域使用哪些服务？
• 正在使用哪个版本的 Linux？
• 哪些应用程序与区域中的其他应用程序通信？
• 哪些应用程序是面向客户的与内部的？

收集这些起始数据点不会回答所有未知数，但它们会开始提供您需要的见解。

审计你能做的：接受不可知的

无论您审核或记录每个细节的程度如何，都会存在影响停机时间、客户、同事、费用和时间表的未知变量。这些未知数只有在技术团队参与迁移过程时才能被发现。您可以通过以下方式支持他们：

• 为未知数添加时间线
• 当未知项目造成问题时，有更多资源可提供帮助
• 灵活应对公司政策、内部会议和新功能推出
• 制定备份计划，例如在测试失败时回滚
• 在规划大胜利时，首先关注小胜利以获得动力。请记住，只要不会导致更多的运营开销，切实的快速胜利可以帮助鼓舞士气。

首选方法是进行完整的审计并记录组织结构和关系，并在整个工作中使用它作为参考。一旦项目开始，此文档将成为您的地图，并有助于避免取消优先级或搁置项目。您可能会发现可能需要上报给高层管理人员来确定您需要推进的行动的优先级。尽管如此，还是应该优先了解各个团队的工作方式并与他们建立良好的沟通，而不是越过他们的头脑。

安全：带 SecOps 团队出去吃午餐

我们并不是说托尼女高音“带他们去兜风”的那种方式。我们真正的意思是带安全团队出去吃午饭，以建立面对面的融洽关系。安全团队对于迁移过程来限制、放松或为出现的阻止程序提供解决方法至关重要。您还需要他们快速审查使您的迁移成功所需的任何新软件。被忽视的安全团队将成为阻碍者。让我们用另一个可怕的电影类比来面对它，安全永远不想成为巨蟒中的黑骑士，尖叫着，“没有人会过去！”但他们真的想扮演确保一切安全的重要角色。最后，只要有适当的指导方针，安全性希望使组织内的每个人都可以使用。如果您及早让他们参与进来，您将避免在最后一刻安检时感到头疼。

Resist Scope Creep：这真是个好主意……明年

范围蔓延需要谨慎管理。所有组织都希望同时解决他们的问题，但您应该专注于解决一个非常具体的问题。以从 Pivotal Cloud 迁移到开源 Cloud Foundry 为例，Cloud Foundry 的主要优势在于可以添加的许多功能和定制的潜力。例如，改善灾难恢复状态和备份可能很诱人，但创建额外的范围会产生额外的痛点。

范围蔓延还会产生一个问题，即某些东西可能会中断，并且您无法确定中断是由您的总体项目目标还是由额外的范围引起的。

镜像：匹配你想留下的世界

一旦您为您的项目建立了参数和期望的结果，您必须确保您已经镜像了所有将被迁移的环境。这包括您的操作环境或“操场”，您将在其中证明之前的一切，转向非生产，最后是生产。

在构建游乐场环境时，您需要确保现有技术（在我们的示例 Pivotal 中）与您的非生产环境相同。这将使您更有信心遇到更少的问题。

管理事项：在高处结交朋友

您将需要管理层的支持，因此不要描绘出完全乐观的画面。移民在他们面前还有很长的路要走。移动平台是一回事，但您还必须处理所有服务。管理层需要了解您的迁移方法以及降低业务风险的计划。管理层会很紧张，因为迁移可能会影响底线，因此您需要讨论所有措施以避免这种情况。

失败得好：让它成功

失败是好的，失败是伟大的，只要你下次吸取教训，就应该预料到失败。你无法解释所有事情，当未知数成为阻碍时，就会发生可察觉的失败。让管理层知道会有失败将有望避免负面含义并提高整体士气。事实上，你需要庆祝从失败中学到的东西，因为你正在取得进步。要出售这种失败是可以接受的，您需要一个明确的后备计划。将此作为您的迁移日计划的一部分，并带有回滚的去/不去决策点。

许可费用和风险是迁移到开源 Cloud Foundry 或 Kubernetes 的主要驱动力。对于运行数千个应用程序的大型组织而言，风险至关重要。随着对规模和开发人员短缺的需求不断增加，迁移似乎存在风险。主要关注的是避免对应用程序团队的影响并避免停机。好消息是，Stark & Wayne 已经执行了许多成功的企业级迁移，这些迁移坚持最小的开发人员影响和仅限于更改控制窗口的停机时间。

通过排除我们遇到的这些常见错误，您的下一个项目不太可能成为波士顿咨询集团建议的 70% 未达到他们期望的部分的一部分。

也在这里发布。