【客户案例】企业敏捷的挑战发表时间：2020-05-14 13:42 挑战 如何协调数上万名用户的工作，平衡团队创新，优化绩效以及遵守报告标准和合规的需求？在强生公司，我们就面临着这样的挑战。有15个 Atlassian 应用程序实例和数万名用户，需要找到一种可行的方法来有效地管理应用程序和用户。一起来了解他们的历程 - 挑战、最佳实践、经验教训以及曾经开展过的最大规模数据迁移期及其带来的投资回报。 大约2014 - 2015年强生开始了一个全公司的敏捷计划。当时有些团队已经开始了敏捷许多年，但这次是希望全公司都能更加敏捷起来，进入企业敏捷。下面我们会分享当时是怎么处理数据整合和转换，我们如何用插件、工作流以及如何处理自定义字段，用户权限等。我们如何来治理，维护，如何持续性的参与其中，制定流程来保证企业敏捷的持续性。 敏捷，这是关于自组织团队，是关于团队以最佳的方式工作，但是当从整个组织的角度来讲，我们不得不考虑例如用于度量、报告的指标，如何来平衡，就是企业敏捷之路的挑战。哪些是需要标准化的，那些是团队可以有更大灵活性的，同时还要考虑到性能、成本以及其他。 我们开始规划大型企业级实例时，我们需要一个支持高峰用户集在20,000用户，有冗余能力保证系统性能，同时也要满足合规需求的系统。 解决方案 我们首先在内部部署Data Center，但我们很快就决定转向高效益的AWS，我们应该是与 Atlassian 合作的迁移到 AWS 的第一家企业。因为我们需要一个确保我们能行之有效的策略和流程。
经过了许多不同的实验，我们找到了一个我认为对我们有用的实践和流程。整个过程分为五个阶段，我们想确保一致性，这个过程中，这有足够的严谨性，可以最大限度地减少在迁移和整合过程中的问题。 合并和数据转换
团队和角色： 我们把团队放在一起，主要是企业 IT 团队，Atlassian 解决方案合作伙伴，源系统负责人，质量合规团队，Atlassian 客户技术经理 （TAM）和 Atlassian Premium 支持团队。 实践
我们找到真正的关键是我们需要花时间去了解不同系统详细的差异。但我们也必须非常清楚，在企业实例中需要完成的任务，在源系统处理的方式和企业目标实例处理方式不一样时，我们将如何处理插件、工作流、自定义字段、权限管理等。 与源系统负责人的每日站会，确保我们对目标有定期进展，记录决策的过程，然后我们试图保持遵循我们企业实例的原则。 在旧系统中有很多不相关的自定义字段，他们被创建只是为了一次性项目的需要，这时我们要评估其价值，因为所有这些都需要付出代价，如何缩短 Lucene 索引时间，保持自定义字段数量是关键，所以我们的重点是保持尽可能低的数量，自定义确实影响了系统性能。 在企业实例中不是每个源系统的自定义字段目标系统都会有，验证了没有必要性的字段，源系统中的自定义字段数据会迁移过来保留成一个或两个可读字段，有过去的标签和数值。为什么有必要这样做是因为有些面板和这些字段相关联。 用户权限模板也不同了。因为很多源系统没有他们的 AD 管理，用户名和密码他们会和企业实例不一样，要确保都与企业实例保持一致。我们使用 Crowd 管理和连接所有 Atlassian 工具，连接我们和 Active Directory 的交互，我们使用 Active Directory 组，用户可以申请访问这些组权限，这些组带入 Jira、Confluence 和 Bitbucket。 第三方插件是一个很大的挑战，兼容性和扩展性都需要重新评估和严格测试。 清晰的理解不同实例的差异，两者之间的复杂性，从技术上的考虑，例如担心潜在的数据库，从Oracle数据库转到Postgre，无论从数据转换的角度还是从验证的角度让每个任务都能自动化。 我们不得不做的一件事是，从源系统到目标系统我们做了百分之百数据验证。 我们在 AWS 中的沙箱环境做了10-20次的测试迁移。 临时环境：
上线
收获
治理和维护方面的最佳实践
|
