这篇关于网络生命周期的博文是这个回归基础系列的第六篇，也是最后一篇。之前的五篇文章都提到了收集需求,网络设计、实现,操作,和故障排除。
一般认为，每个网络都有一个生命周期，并且模型可以代表这个生命周期。无论您使用的是图1中显示的六步模型、图2中显示的三步模型，还是完全不同的模型，所有的模型都有一些公共元素。
决定将网络生命周期的元素放在模型的哪个盒子中通常是一个挑战。其中一个主要原因是许多元素出现了不止一次。另一个原因是，一些因素可能会模糊角色和责任的界限。下面是常见元素的列表。你会把它们放在哪个盒子里?
信息收集
最明显的信息收集形式是需求。本系列的第一篇文章讨论了收集设计初始构建的需求。说实话，需求收集从未停止。业务需求会随着时间的推移而变化，业务所依赖的应用程序也是如此。网络需要跟上这些变化的步伐。
还应收集关于现有和新建网络的资料。日常信息应该包括CPU利用率、带宽利用率、内存利用率、误码率和数据包丢失等等。故障分析报告也是改进系统的关键信息。
信息分析
日常信息是最容易处理的，因为它已经是一种技术形式。这些信息将揭示网络设备和链接的大小是否合适。
与操作信息相比，故障分析报告通常需要更多的关注和努力。如果网络没有像预期的那样响应故障事件，则必须确定设计是否需要改进，或者在实现过程中是否发生了错误。
业务和应用需求通常需要花费大量精力。这种类型的信息总是需要转化为技术需求，以合并到设计中。如果每个应用程序都以一种有意义的技术格式清楚地说明它们的网络需求，那就太好了。然而，这样的应用程序文档比摇摆马粪更少见。
架构和设计
本系列的第二篇文章“网络设计”讨论了创建高级和低级设计文档。高级文档被称为体系结构，而低级文档被称为设计。根据组织及其劳动分工，不同的资源可能负责生成每个文档，或者相同的资源可能负责生成两个文档。毫不奇怪，这些资源的作用是将技术信息转化为网络架构和设计。
架构和设计资源应该始终检查从业务或现有网络收集的新信息，以确定是否需要更改或优化。保持这个过程的真实性有助于创建和保持一致性。一致的网络体验有助于企业、应用程序、用户和负责维护和操作的资源。
实现和测试
网络的最初构建在推广到生产之前应该通过几个关卡。虽然可以在实验室设置中验证配置和一些操作，但应该在具有合成流量的生产设备上执行带宽、错误率和弹性测试。试图支持生产工作负载并不是找到可能通过严格的概念证明暴露的问题的最佳时机。
对生产网络所做的更改很少不需要严格的测试。任何影响交通流量的修改(例如，改变交通流量，限制交通流量，增加交通流量)都应该进行测试。对弹性和故障转移设置的任何更改都需要进行测试。
您的组织可能已经创建了一个业务连续性计划(BCP)，其中包括到备用站点的灾难恢复(DR)。该计划应该包括对所有容灾组件的定期测试，以确保它们在灾难发生时能够按照设计的方式工作。
操作
一个好的运营团队可以让一个糟糕的设计在一段时间内让企业可以忍受。一个疏忽的操作团队甚至可能导致设计最好的网络像一辆生锈的老古董一样行驶。网络需要以安全补丁、bug修复、升级、有效的故障排除和监督的形式予以关注和支持。
应该记录重复出现的问题，并与体系结构和设计资源共享这些问题。这个过程需要双方良好的沟通和健康的关系。在没有咨询架构和设计的情况下实现简单的设计更改是很诱人的。无论设计更改看起来多么无害，最终的决定取决于架构和设计。该规则支持上述连续性和一致性论点。
一个网络工作者的工作永远做不完
我已经在这列柱子中讨论了迭代，所以它是合适的尾部。
现在应该很明显，社交的任何一部分都不是一蹴而就或一劳永逸的。的瀑布当应用于网络时，这种方法通常会导致次优结果。迭代允许在网络生命周期的每个阶段进行重复。它还允许前进和后退运动之间的阶段。这种运动的自由导致在每个阶段进行微调，并使新信息更容易地整合，减少返工的负担。
现在继续前进，建立关系网，循环往复地走向成功。
阅读我的其他博客系列
收集需求
