运维的变化

 

作者：简胖
链接：https://www.zhihu.com/question/442323148/answer/1709512854
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
 

运维的要求越来越高了，同时运维的生产力也在不断的提高

最开始只是最常见的分布式部署，用来应对高并发和高可用，这时候就是需要会一些高可用配置，集群部署，自动化工具就可以应付了。

随着互联网业务的不断发展，开发那边提出了敏捷开发，发布的频率变得非常之高，这个时候就需要运维这边能够做好相应的支持，也就是devops。

然后随着微服务化，服务的编排与调度就变得非常重要了，这个时候对运维的要求就是docker与k8s。

然而仅仅靠编排与调度并不能满足越来越多的微服务的管理需求，如果全指望开发来解决微服务治理（服务降级，熔断，灰度等等）功能难度很大，于是把微服务治理这一块的事情也交给了运维，那就是server mesh，这样开发就只要专注业务，不需要花时间在微服务治理。

到现在这个阶段，因为微服务的规模实在是太庞大了（几万，几十万以上的pod），而且每天又有几百上千次的服务发布，维持系统的稳定性就成为了巨大的难题，任何一次的发布都可能会影响到整个系统的稳定性，系统也会存在越来越多的隐患，传统的测试方法在此时已经失效，这个时候对于运维的要求就是混沌工程。

未来的话，也就是通过机器学习来不断的调整和优化来保障系统的稳定性了，但是这个在很长时间内，只会存在于大型的公有云服务商和大型互联网公司，因为机器学习也是需要巨大的算力和海量的训练数据来提高准确度，算力这个还好说，海量的训练数据，一般的公司都很难有，唯有公有云服务商，可以很容易获取大量的客户运维数据来对AI进行训练。