Azure DevOps Service 超出使用限制

1. 概述

Azure DevOps Service是微软公司软件开发运维一体化的云服务产品；作为一款为IT团队提供应用软件生命周期管理的云服务器产品，服务器中存储了大量的研发数据，包括需求、缺陷、源代码、测试用例和持续集成等各种数据；随着企业业务发展和变化，IT数据会随之不断增长，尤其对于一个大型企业来说，数据的增长可能会超出管理员的预期；如果不提前了解和监控Azure DevOps对于存储数据的限制，可能会突然发现自己的团队数据已经达到了Azure DevOps云服务的限制。

在监控系统的使用限制时，微软的Azure DevOps提供了实时监控工具，包括团队项目集合（Project Collection）层级的监控、团队项目（Projects）层级的监控，本文介绍如何使用这个监控工具，以便提前做好数据规划。

注意，作为企业内网部署的版本（Azure DevOps Server），目前最新的版本没有使用限制。

2. 团队项目集合（Project Collection）

在团队项目集合的设置页面中，选择概述（Overview）菜单，可以看到团队项目集合的使用限制状态，目前的版本包括两个指标：团队项目个数、工作项标记个数

团队项目个数：在每个团队项目集合中，最多可以创建1000个团队项目工作项标记个数：在每个团队项目集合中，最多可以创建15万个标记Tags

3. 团队项目（Projects）

在特定团队项目的设置页面中，选择概述（Overview）菜单，可以看到团队项目的使用限制状态，目前的版本包括五个指标：团队个数、仪表板个数、交付计划个数、区域路径个数、迭代个数

团队个数：每个团队项目中最多创建5000个团队仪表板个数：每个团队项目中最多创建500个仪表板，单个团队最多500个仪表板交付计划个数：每个团队项目中最多创建10000个交付计划区域路径个数：每个团队项目中最多创建10000个区域路径，每个团队最多300个区域路径迭代个数：每个团队项目中最多创建10000个迭代，每个团队最多300个迭代

4. 题外话

前面描述了两个层次的数据对象的限制；为什么微软开发团队要对这些数据做出限制呢？

其实也是来源于项目实践，在大型的开发团队中，由于数据量的多年积累，加上目前还不能按照年度或数据类型实现数切割，出现性能问题是十分常见的现象；笔者最近和微软产品团队解决过企业内网Azure DevOps Server的的性能问题，原因就是数据量太大（15TB），光团队项目就有近500个，硬件服务器已经按照最高配置，但是在早晚高峰时间点会出现卡顿现象，CPU使用率超过80%；出现这种问题的根本原因是最初规划时没有将不同类型的研发团队分割在不同的团队项目集合中，导致工作项数量、工作项关联数量、源代码数据和持续集成数据太多，用户还使用了大量的仪表板，综合各种情况，于是出现了性能问题。

因此微软对Azure DevOps Service中的数据量设置限制，也是有一定道理的。为了避免触发限制导致突然出现故障，我们在部署系统之前，必须要结合Azure DevOps的系统设计机制，结合企业内部的业务场景，提前从团队项目集合、团队项目两个层次，对系统做出科学的规划。

https://www.cnblogs.com/danzhang
Azure DevOps MVP 张洪君