衡量IT基础架构规模和复杂性的措施是什么

#1 楼

TL; DR：规模的度量可以大致分为三类，我将其定义为您管理的内容与服务外包或作为服务使用的内容的深度，
支持的服务以及实例，服务器和
客户数量的高低。复杂性的度量很大程度上取决于所选的系统架构，支持该架构的人员的组织结构以及所需的技能。深度和技能组合在一起的地方
既增加了尺寸又增加了复杂性。


尺寸测量

注意：以下大多数尺寸要求还会通过系统架构，技能集和组织结构需求而增加复杂性。

基础架构的深度：


您是否将软件即服务简单地用于您所做的所有事情？
您是否在公共云，私有云或混合云中完全运行，或者使用某些服务PaaS？
您是否使用基础架构即服务？
您是否在租用的DC空间中使用托管和托管基础架构？


您是否拥有或租用硬件？
提供商可以管理基础架构监视吗？
提供商可以管理基本的系统管理吗？
提供商可以管理硬件故障和维护吗？
提供商可以管理机架和服务器安装吗？ br />供应商管理内部网络吗？
供应商管理互联网连接和路由吗？


您是否拥有带有签约远程操作的数据中心？
是否托管所有内容在内部还是在自己的数据中心中？

基础架构的广度

您支持的服务类型有哪些？


计算资源


裸机服务器
虚拟化层（VMWare）
无服务器层（lambda，函数）


存储资源


独立存储设备
服务器中的RAID
大型独立关系数据库集群
时间序列数据库
对象存储群集


网络资源
可观察性资源

系统日志服务器
度量和图形系统
搜索群集


自动化资源
备份/恢复资源
复杂的复合服务


ELK，Hadoop等



基础架构的高度


您需要的每种资源的规模是多少？您是在单个服务器/实例上运行服务还是需要使用计算机集群？
您需要什么冗余级别？
您的可用性要求是什么？
您有什么要求？服务的延迟和吞吐量？
您需要地理上分散的基础架构吗？ （国际业务，延迟要求或GDPR，数据本地化法律等法规合规性）
每个地区是否需要多个数据中心？

复杂性度量标准非常简单...

系统架构

当涉及到基础架构复杂性时，它非常接近基础架构所支持的分布式系统的复杂性。您必须考虑两种类型的系统：


支持单个服务的分布式系统。
由服务的相互依赖关系创建的分布式系统。

分布式系统的复杂性

基础架构支持的每项服务本身都会具有不同级别的复杂性，并且对基础架构的要求也各不相同。系统支持服务的范围包括：


单线程。
多线程（共享内存，共享磁盘）
具有数据分片的并行系统
HA故障转移（主/备用）（冷，热，热）
HA群集（N + M）
实时集群

服务的相互依赖性

让我从一个例子开始。假设您的基础架构将测试结果报告到ElasticSearch集群中。您的寻呼机取决于ElasticSearch提供的监视和测试数据。 ElasticSearch群集的地理分布使其取决于您的数据中心网络连接。现在，您的互联网提供商之一决定在周六晚上进行不通知的维护，吞吐量下降，您的流量被重新路由到备份提供商，监控流量被降低为客户数据流量的优先级，监控事件的接收速度变慢并且寻呼机发疯。

每当两个服务，基础架构的两个部分相互依赖时，它们就会创建一个新的单一分布式系统，其复杂性应独立判断。可以删除或减少这种依赖性。请记住，系统只是它所依赖的所有服务的交叉点，才具有冗余性和可用性。

复杂性增加因素的其他示例：外部服务。
尝试减轻由于服务依赖性引起的故障。


多个提供程序
数据缓存/>组织结构

这本身就是一章……人们经常被人们忽视，这是整个IT基础架构系统的一部分。我们很少考虑人的冗余，可用性和延迟因素，但是就像计算机一样，这些相同的问题也会影响组织维护基础架构，而其复杂性有时可能会轻易超过计算机系统的复杂性。维护基础架构的人员可以跨越多个时区，语言，地理位置，公司，薪级表和法律法规。这些因素中的任何一个都是复杂性增加的迹象。