认识达内从这里开始

网络运维是随着互联网的不断发展而逐渐成为求职热门岗位之一，而今天我们就一起来了解一下，关于互联网网络运维我们需要注意和学习的一些要点。

1、CEO要亲自抓“业务连续性”

互联网行业对于技术常说的一句话是“开着飞机换引擎、高速公路换轮胎”，这里面透着对于技术支撑业务高速发展的自豪，但是成功的背后是一次次的宕机，通过不断试错和快速恢复才慢慢支撑过来。这样的代价在业务早期还能支撑，在互联网成为基础服务的今天，代价越来越无法承受。疫情之下，互联网业务的中断，已经不是一家公司的事情，而是成为了影响国计民生的大事件。

银行一直特别重视业务连续性管理，把业务连续性上升到承担社会责任的高度。大家可能不知道的是，银行关键系统故障超过2小时要报银监会，超过4小时要报国务院。在这样的压力下，才催生出“两地三中心灾备体系”、“高冗余”、“应急切换”等业务连续性解决方案。互联网公司的CEO，需要把业务连续放到和业务增长同样的高度来看待。

2、CTO正确看待”稳定运维”和“敏态运维”的利弊

银行是稳态运维的代表，互联网是是敏态运维的代表。大家都知道稳态的优点是安全，代价是不敏捷，但潜意识里面认为互联网运维的敏态是既敏捷又稳定，敏态比稳态更加先进。

但事实上，敏态是在效率和安全上寻找平衡点，这个平衡点往往和互联网的风险意识以及投入是相关的，大部分敏态运维没有考虑一些极端情况。另外，互联网运维经常宣传的一个人运维几十万台服务器，也是有一些误导效应的。场景不一样、安全要求不一样的情况下，单纯对比运维的人效是没有意义的。

3、数据中心负责人不但要保安全，还要防风险

互联网的安全部门，银行数据中心叫风险管理，虽然安全和风险的职责类似，但是含义不同。互联网强调的是对安全事件的快速响应和快速处置，更多情况下安全还是防范外部风险。银行的风险管理，则是默认认为人是不可靠的，防范内部风险和外部风险同样重要。风险管理、安全响应、内审、外审，尽量实现岗位和人员之间的相互制约。风险无处不在，业务跑的越快，面临的风险就越大。

4、不要通过技术手段解决管理问题，承受必要的管理代价。

必须承认，微盟的事件，技术上是无法预防的，多只能降低损失。互联网公司默认运维人员必须7*24小时待命，VPN是和笔记本电脑一样的办公标配，随时随地可以接入生产环境操作。

银行则是严格执行开发和运维分离，生产网和办公网分离，root权限按需申请，在特定的在ECC机房使用特殊终端才能操作，变更操作需要双人复核，开通VPN需要申请、说明理由并指定时段等等，这一系列措施都是银行一直以来默认的规则，导致很多银行运维人员很难理解为什么会发生微盟这样的事件。代码会有漏洞，人是不可靠的，物理上的限制和流程上的控制，虽然会降低效率，但是只有技术和管理并重才是双保险。

5、运维开发和运维操作的团队必须分离，重视运维平台的非功能需求。

互联网早期的运维开发都是运维人员兼职，自己给自己做工具，追求的是效率和灵活，都觉得自己做的鞋合自己的脚。但是这样的问题是，运维人员既当运动员又当裁判员，对风险防范、性能等非功能需求缺少考虑。随着人员和规模的扩大，潜在风险越来越高。

运维平台的本质是管理工具，需要固化管理策略和风险防范来约束人员的行为，抵御黑天鹅事件。设置独立的运维开发团队，同时面向管理员和管理者，兼顾效率和风险的需要，是互联网公司运维平台的发展方向，毕竟不稳的情况下快是没有意义的。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!