查看原文
其他

IT安全生产运行可不仅仅是IT团队的事

苏文力 看懂经济 2019-05-25


文 | 苏文力

阳光保险助理总裁,看懂经济专栏作家

苏文力的其他优秀作品

管理者到底应该怎么授权?

315痛批用户隐私泄露,数据安全该何去何从?

大多数培训学习都只是走过场

怎样的IT工作才会让金融高层领导满意?

银行做金融科技公司,或许那不是你的菜

 

IT安全生产运行对于现代企业的重要性不言而喻。很多领导和业务人员会认为那是IT团队自己的事情,IT团队也缺乏站在企业整体角度去思考安排IT生产运营工作的意识,相互没有拧成一股绳,影响了IT生产运行稳定性。

 

  ◆  

一、风平浪静意味着下足了功夫


一次出差正好遇到当地分行发生IT生产事故,半夜里被其IT负责人从招待所里拉到机房帮忙。说起来故障并不大,带来的影响很有限。很快就定位了问题所在并形成了应对方案,只需个把小时就能够将一切恢复正常。这时候看到这位负责人拿起电话,与其分管行领导联系,汇报发生的事故情况和善后措施。


这让我感觉有些不解。事故并没有带来太多的负面影响,问题原因也已经找到,很快就可以恢复正常。没有什么特别需要请示领导的内容,完全可以第二天上班后再汇报。深更半夜打扰领导,应该还有其他考虑。等其电话结束后,就赶紧询问这么做想要达到什么目的。


基于相互间良好的信任关系,他非常坦诚的告诉了我原因。一方面是想给领导留下比较深刻的印象,使其明白IT工作压力大,也很辛苦,大家都非常尽责和努力;另一方面为第二天获取解决问题所需资源做铺垫。果然随后领导没有追究事故的责任,而是选择充分信任,并提供了后续亡羊补牢所需要的资源支持,他们分行的IT运营水平就此迅速提升了一个台阶。


进一步了解后得知,他这样做也是被教育的结果。过去发生类似事故时,他选择把事情处理好,不打扰领导。结果领导以为IT中心没什么事情,不需要太多关注,也就没有给予必要的支持,年底对IT中心也没有很客观的考评认可。这让他反思,发现必须让领导平常切实体验到IT中心工作的不容易,才能够得到领导的认可和关怀。


许多分管IT的高层领导,并非IT专业出身,对于IT生产运行没有太多概念。加上日常其他工作缠身,难以抽时间实地调研学习,很容易雾里看花、不明就里。以为IT中心生产运行工作一切正常是很自然而然的事情,没有什么难度。反而对于出现事故熬夜加班,妙手回春的神奇表现印象深刻。这变相鼓励大家忽视日常防范生产风险,而热衷于临时凭急智和运气去应对事故。


孙子兵法云“善战者,无智名,无勇功”。善战的人,都是准备充分,按部就班,执行中没有太多意外,打的仗也就不精彩,没什么可以歌颂的故事。人们所推崇的名将,靠临时决策,能够打赢不可能打赢的仗,但最后往往是惨痛失败的结局。随机应变里有很大侥幸成分,无法持续重复胜利。IT生产运行也是如此,平常做了充分准备,也就不会出现太多意外,即使出现个别故障,也能够很快恢复正常。


稳定的IT生产运行不是靠运气好。短时间可能有运气成分,但长期来看一定是自身能力在起作用。肯定做了大量艰苦细致的工作,将可能的风险化解掉了。这些工作成就,难以被直观看到,也就难以被认可。领导要尽量与IT团队交流,努力了解其日常工作情况,感受其专业付出和责任担当。要及时给予肯定,提供必要的支持,鼓励他们将工作做在前面,减少各种隐患和不确定性。

 

  ◆  

二、平淡无奇的日常招数


减少不确定性有很多方法。记得多年前我负责新开发的大型应用系统投产上线,来自国外的一位技术专家帮助确认投产前的准备情况。我自认为一切准备就绪了,向其展示投产所需要提交的全部程序作业,必要的系统环境部署配置,前期的测试演练结果等等。但其很快发现并指出我没有编写投产工作清单。


一开始我有些不以为然,认为自己脑子够用,没必要多此一举。专家非常坚持,只能按其要求去做。我们针对每个投产环节开展讨论,假定可能出现的各种情况,发现的确有很多情况考虑不周。清单可以让大家看到将要做的所有动作,让更多人参与讨论,通过纸上推演,发现潜在的问题。按照清单进行测试演练,可以实际验证投产准备活动的质量,降低投产发生意外的概率。


投产那天,我对照清单要求按步骤操作。有位同事在旁边专门负责记录和提醒,其他一些同事在各自岗位提供配合支持。根据操作后系统所显示的状态信息,对照清单与同事确认后续的操作内容。由于准备的充分,投产过程非常顺利。让我明白了清单式管理是非常好的生产管理工具。后续在行里积极推行该方法,效果相当不错。


原本以为应用清单管理做的不错了,但在一次与德国储蓄银行IT中心的交流活动中,找到了差距。该行IT应急预案流程工作清单摞起来竟然约一米厚,详细到没有任何遗漏,任何问题出现都可以立即找到明确的行动指令和具体要求。除技术方面外,还包括所有涉及到的领导和业务部门的详细任务内容。对比发现,我们的清单管理还只是初级水平。不论是内容全面性还是细致程度都有很大提升空间。



IT设备和系统架构要安排容错配置,确保部分节点出现问题,还有其他节点可以继续工作。要注意减少涉及的供应商数量和设备系统品牌型号数量。多品牌型号设备和系统间容易存在相互兼容问题,各个厂商及服务团队很可能因此相互扯皮,难以协同,影响排除故障的时效。有些关键设备和系统节点也不能仅仅采用单一品牌或型号,确保其中某一品牌型号设备和系统因特殊原因都瘫痪了,还可以有其他替代选择。


设备随着使用年限的增加,稳定性会逐渐降低。过了一定期限后,故障概率会大幅提升。不要为了省钱而继续将其放在关键节点上使用,一定要坚决更换。可以让其作为测试用机继续发挥作用。曾经公司有一关键设备快到使用年限,因采购衔接问题,更换延误了几个月。结果在新设备到来之前,旧设备发生了较大故障。现在想起来还很后悔。


生产上该花的钱一定要花,有些钱不能省,但花再多的钱也不能让IT生产运行百分百安全。有些新技术被宣传的神乎其神,但是否适合你的公司需要仔细思考。即便适合,能够带来多大程度的生产稳定性改善也需要认真衡量。这里面也存在边际效益递减的状况,达到一定稳定性程度后,继续采取措施能够带来的改进效果会很有限。期待完全不出问题并不现实。应要求出现问题不影响大局,即使出现灾难性状况,也能够有最基本的生产保证。


变更设备、系统和应用程序是最影响IT运营稳定性的因素。要尽量控制生产变更,减少对生产稳定性的冲击。不要把一系列变更都攒在一起执行。太多变更在一起会增加复杂度,容易引发故障,且很难快速定位是哪个变更引起的问题,导致需要更多排除故障时间。要根据风险状况,适当平衡变更次数和一次变更规模之间的关系。


有些业务人员认为一些极小改动的变更需求,对生产影响不大。殊不知所有的变更都有风险,都需要认真排除可能的隐患。曾经有一次为了应对业务紧急状况,修改了几行程序,自以为很有把握,为了赶时间没有充分测试就安排投产。很不幸,恰恰当天有一些平常不会出现的业务状况发生,触发了该变更的隐患,导致系统出现异常。幸亏发现及时,没有造成大事故。

 

  ◆  

三、更多的信任和参与


前期大量细致的风险控制工作可以降低事故发生概率,但一定仍会有事故发生。虽然很让人沮丧,但只能积极应对。事故处理人员必须保持冷静,任何头脑发热都可能带来更坏的情况发生。要先想办法把系统恢复起来,而不要纠缠怎么就发生了事故。可以先从最可能引发问题的那部分去发现解决问题的关键点,然后逐步排查。最常见的故障触发原因是最近进行的生产变更,或外部关联系统发生了较大变化。


领导要保持镇定,不要再额外给相关人员施加压力,避免不断询问进展打扰他们。要相信专业团队能够将问题搞定,也唯有相信他们才会让他们心无旁骛的去开展工作。记得第一次经历较大系统故障,正好与该IT中心负责领导在机房楼上开会,他接到电话后说出事故了,然后就继续与我们讨论原来的话题。


他是技术高手,处理故障的经验很丰富,但他选择相信下属。现在还记得他的话:“让他们搞,若有需要或进展肯定会有报告的。”果然不断有消息传出来,问题逐步被解决,一切恢复正常。他那种镇定给我留下了非常深刻的印象,成为我日后效仿的榜样。


要对发生的事故检视复盘,找出存在的问题隐患,通过举一反三,让整体运营水平有所提升。当企业领导强调要处理事故责任人时,大家的心思会局限在怎样保护自己,避免被追责上,难以真正去思考未来怎样不掉进同样的坑里。事故的关键原因很容易被隐藏或忽视,只是找到些替罪羊和一些非深层次的毛病。


寻找为什么会发生问题,谁在其中,都做了什么,是面向过去的检视提问,会触动大家的自我保护意识,很难展开真正的反思。要面向未来提问:我们从中学习到了什么,未来更好的IT运行安排是什么,更加有效的IT运行策略思路是什么。这会让我们在潜意识里检视那些曾经考虑不完善的方面,但并不会感觉有压力,不用担心被追责,会全力寻找未来正确的方向和基于此的改进举措。



业务方面对于IT生产运行稳定扮演着非常重要的角色。有些系统架构比较陈旧,随着新功能在上面不断叠加会让系统越来越脆弱。只有系统重构才能彻底解决问题,但开发基于新架构的系统会占用大量IT资源,在相当一段时间内可能要冻结业务新需求。必要的业务创新很可能需要依靠业务人员通过手工处理来过渡,甚至可能会错失一些市场创新机会。业务与IT应坐下来一起商量,寻找其中的平衡点。一味要求IT必须满足所有的业务要求,最后的结果很可能事与愿违。


有些时候IT对于业务到底要什么并不十分清楚,很可能存在资源投入方向偏差。最近在一次教练式领导的培训课程上,一家公司负责业务运营的领导和其IT团队的负责人正好凑到一起开展对话训练。所谈的话题就是怎样让IT系统稳定性能够满足业务经营发展的要求。相互间开放且有针对性的提问,耐心的倾听,让双方都有很大收获。


IT负责人终于比较透彻的了解到业务到底需要什么,发现过去很多资源没有放到业务关注的核心领域,IT团队很辛苦,但效果却不佳。业务方面发现过去只是认为IT不给力,没想到IT面对大量的业务需求难以取舍,使得系统越来越复杂,而若能够进一步明确简化要求,IT就有机会走出困境。大家发现,协同变通可以让技术绕过障碍,减少系统关联复杂性,IT系统稳定性就此能够提升一个数量级,就可以大幅提高公司核心产品的对外服务能力。






欢迎加入顶级学习研究资源群/工作与实习信息分享群/硕士博士交流群


扫描二维码,根据自己的需求加入相应社群


<  end  >


如果您对本文有好的想法,就留下您的宝贵建议吧!


看懂经济热文   点击即可查看

1、兴业银行董事长高建平:战略筑就远航的灯塔

2、银联下乡,农民上网,乡村振兴卡振兴乡村

3、服务小微31年,这家城商行为什么会有互联网的发展速度?

4、衣穿淘宝,食有美团,行用滴滴,住在贝壳!

5、1岁多就IPO,唯快不破的瑞幸能否打败稳扎稳打的星巴卡?

你的每一个“在看”,我都当成了喜欢!

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存