敏捷开发需要敏捷支持

敏捷开发已成为应用程序开发的标准方法。漫长的计划、巨大的甘特图瀑布图和详细需求的日子正在消逝。多年来，产品规划过程让产品负责人和企业感到沮丧，因为无论计划如何，事情总是不按计划进行。敏捷开发抛弃了详细的计划，而是侧重于给予开发人员一些基本需求，并指明正确的方向。通过快速迭代与最终用户、产品负责人和开发团队的持续协作，有助于确保项目能够正确完成。

各种敏捷开发方法在加快产品创建方面发挥了巨大作用，但也带来了一些新问题。复杂的应用程序部署现在每周或每月发生。大多数产品都是基于 Web 的，并以软件即服务 (SaaS) 的模式进行部署。这些应用程序的系统性能和可用性变得至关重要。这与过去每季度或每年一次通过 CD 邮寄新版客户端-服务器应用程序的旧流程截然不同。

源源不断的新产品和产品增强给 IT 运营带来了巨大压力，要求 IT 部门跟上软件部署和增加基础设施容量的步伐。问题在于，由于变更单、文档、流程、测试和其他流程，大多数运营团队的行动仍然缓慢。在某些组织中，运营部门可能会拖慢进程，甚至抵制开发团队。DevOps 运动正试图通过将开发和运营团队更紧密地集成在一起，来解决其中一些问题。

快速变化带来新问题

快速的产品变化最终会在过程中产生一些应用程序问题。更高的变化率会增加新应用程序缺陷的可能性。将应用程序作为软件服务交付也意味着应用程序的可伸缩性至关重要。开发团队在应用程序缺陷和可伸缩性问题上苦苦挣扎。

修复应用程序问题是敏捷开发团队一项永无止境的工作。在客户发现之前修复问题并快速修复它们至关重要。由于开发和运营部门之间的隔阂，大多数公司在这方面都非常挣扎。修复应用程序问题通常需要查询数据库、查看日志文件、审查配置文件、审查错误日志和其他类似任务。当首席开发人员忙于处理上一版本产品的缺陷时，就很难进行新功能的开发了。

开发人员需要更多可见性

问题在于，大多数开发人员无法访问生产环境中的服务器和应用程序信息。运营团队不信任将“王国之钥”交给所有开发人员，让他们登录生产环境并随意浏览服务器。挑战要么是完全不给访问权限，要么是可能授予过多权限。有访问权限的人仍然可能浪费时间去弄清楚应用程序的位置以及如何通过 VPN 连接到它。此外，在测试环境中重现问题需要花费太多时间，而且并非总是可能。

系统管理员花费大量时间帮助开发人员跟踪服务器信息。

大多数公司允许关键开发人员访问所有生产资源，以便他们能够帮助解决应用程序缺陷。问题在于只有关键人员才有访问权限，他们就成了瓶颈。他们每天花费 25%-50% 的时间来尝试解决应用程序问题，因为他们是唯一有权访问的人。这些关键员工的时间最好花在新项目上，而不是处理应用程序缺陷。这项工作应该由初级开发人员来承担，前提是他们能够获得排除问题所需的所有信息。

敏捷应用程序支持的解决方案是给予所有开发人员对生产环境的有限访问权限以及他们需要查看的所有服务器信息。一些公司内部创建自己的解决方案来收集日志文件、集中错误或其他事物来解决问题。一些开发人员甚至可以访问服务器监控或其他工具。但关键在于让他们能够访问所需的一切，以便他们能够看到完整的图景，并将访问权限提供给整个团队。将访问权限提供给每个人可以扩大应用程序支持团队的规模，并围绕提供改进的应用程序支持进行协作。

Stackify 实现敏捷应用程序支持

Stackify 提供了一个解决方案，可以让所有开发人员安全地只读查看整个生产服务器环境，而无需控制台或远程桌面访问。他们提供了一个 Web 应用程序，可以实时了解开发人员需要查看的重要信息。以应用程序为中心的视图使他们能够查看跨越多个数据中心和环境的所有应用程序。他们不需要知道应用程序部署在哪里，只需要知道应用程序的名称即可找到它并深入查看更多内容。所有开发人员都可以查看服务器运行状况、应用程序运行状况、日志文件、配置文件、Windows 事件查看器、部署历史记录、应用程序注释等等。当出现问题时，他们可以接收电子邮件和短信警报，甚至可以安全地查询生产数据库。

Stackify 使进行敏捷开发的公司的应用程序支持团队能够通过让更多团队成员参与进来而扩大规模。首席开发人员可以花费更多时间在新项目上。应用程序问题可以比以往任何时候都更快地得到修复。运营部门可以减少帮助开发人员收集服务器信息的时间。敏捷应用程序支持从 Stackify 开始。