要用发展的思路推进技术建设和落地

2020 年 3 月 17 日

要用发展的思路推进技术建设和落地

我们提到一定要避免非黑即白的思维模式,跨越了这个障碍,很多事情就可以做起来了。


当我们做完第一步,标准和规范都出来了,怎么去落地的事情就来了,如果这个时候我们的注意力和精力仍然是盯在标准化本身这个点上,我们会发现推进落地会很困难,因为是标准化了,是规范化了,但是开发的同学如果仅仅是为了配合标准和规范去改造,一开始可能是有意愿的,但是越往后就会越不配合,问题在哪儿呢?


问题出在我们没有想清楚标准化的目的是什么?标准化之后还应该做什么?所以这个问题没想清楚,我们眼光和精力就会放盯在标准化这个点上,而忽略了周边配套的自动化体系建设,自然而然的开发同学感受不到配合带来的收益,配合意愿自然下降。


当然,做好标准化紧接着去做自动化,是顺其自然的事情,貌似应该不用讲的。但是按照我们实际的经历,真正实践起来,还是有很多值得回味的地方。当时我们也是按照套路来玩,先标准化,然后去推,但是效果不好,期间也在做自动化,但是做完了自动化发现自动化的东西又不好落地。


要有发展的思路


后来我们干脆换一个思路,把推广的动作放下。而是把精力都放到发布系统、监控、稳定性相关的全链路、限流降级等系统的开发上,因为我们想清楚一个逻辑,这些系统都是根据我们的标准化来做的,业务要想更方便和高效的发布,应用就得标准化,接入了发布系统,自然而然就得按照我们的发布流程来,要想更快的定位问题,就得用监控和全链路,首先得标准化,要想更加稳定,就得用限流降级和开关预案系统,前提还是得标准化。


再后来,我们就是进行相关产品的介绍和说明,接入的事情都是主动配合的,运维的同学更多的就是做一些指导和问题的答复。


所以,用发展的思路来规划,用更大的目标去牵引,跳出标准化这个框框,不把眼光死盯着标准化这个事情上,反而会有更大的价值和效果,而且原来的问题也都变得不再是问题。边界外的突破往往比边界内的极致优化会带来更大价值。


我们可以看到很多的大厂不断地在扩张发展,其根本目的就是为了解决发展过程中的问题,比如阿里一开始做淘宝,后来遇到了支付信用问题,后来就产生了支付宝,再往后遇到了物流效率和容量问题,后来就有了菜鸟物流,再比如阿里云就是为了解决资源效率和基础运维效率问题。我们可以看到,其实所有这一切都是为了服务好电商体系和业务,这个时候只有通过不断的发展和创新才能根本解决问题,如果仅仅是纠结在问题本身去优化估计很难有大的突破,比如支付问题当时如果总是依赖和等待各大银行去解决淘宝的支付问题,估计不要说支付信用,可能当前双 11 每秒十几万的支付都是天方夜谭。


当然,现在支付宝、菜鸟、阿里云等等,已经不仅仅是在解决阿里电商自己的问题,他们外延出来带来的社会效益都已经是不可估量的了,我想这个就是靠发展的眼光和思路带来的意外中的必然收获吧。


国外大厂,国内 B 和 T 就不用说了,其他像美团王兴也表达过类似的观点,乐视的生态体系也是类似的思路,所以不管是创业还是做技术本身,我想有很多道理都是相通的,这些道理理解了不是说一定去创业,其实对于个人的发展也是大有裨益。或者说不要有这种反正我也不创业,所以这些大道理对我也没用。我觉得所有想要有所发展的同学,都要有点这样的发展的眼光看事物的意识和能力。


任何时候,任何阶段,都不能忽视发展,如果总是盯着眼前的问题,也终将会被困死在问题上。


除了上面标准化推进过程中的案例,下面再讲个在发展过程中,驱动我们改进团队协作方式的案例。


团队协作和技术运营的问题


在发展过程中还有个团队协作和技术运营的问题。场景是这样的,标准化也做了,自动化也做了,有个阶段推进的效果仍然不好,后来我们发现很重要的一点就是应用运维和运维开发脱节的问题,通常标准都是应用运维的同学来定,而自动化的系统是运维开发的同学来做,如果两个团队的同学是各顾各的搞,就很容易脱节,就会出现标准化定好了,没有配套的系统支持,推进不下去,而自动化的系统做完了,没有应用运维去跟业务开发同学去协作落地,自动化系统就是一个摆设,根本起不到作用,如果运维开发做的东西还偏离了应用运维的标准,这个时候问题就会更大了。这里其实是一个运维团队内部协作的问题,其实就是技术运营的问题。


所以,我们中间遇到这样的问题后,就强制两个团队必须得能够协作起来,运维开发的系统必须是应用运维的需求,而且要经过评审,不能想怎么做就怎么做,同时运维开发完成的系统,应用运维必须要能够推广落地,不能说提了需求,也完成了,但是后面不用。


一开始措施都是强制的,但是随着团队协作的紧密,原来遇到的一些问题也慢慢逐步被消除掉,大家共同产出成绩结果,也获得认可,这样成员之间彼此的信任建立起来,默契也就出来了,再往下嘛,就是搞基咯。


这个就是要求团队和平台建设必须持续发展和进步的过程中,获得了促进团队协作改善和完善的效果。


总结


最后,还是用个更形象的生活例子说明,小孩子离开妈妈的母体出生后,抵抗力是很差的,很容易生病或被各种病菌感染,因为太弱小了。但是随着小孩子你年龄的增长,运动量大了、吃的东西多了,小朋友的身体也在不断的成长着,这个时候抵抗力就会越来越强,等到了 15 岁之后,基本就不会太容易生病了,所以随着成长和发展,以前小时候的问题不再是问题了。


本文转载自成哥的世界公众号。


原文链接:https://mp.weixin.qq.com/s/NO_omKyOg8c2ces9Mwl9pw


2020 年 3 月 17 日 22:10187

评论

发布
暂无评论
发现更多内容

架构师训练营第4周学习总结

不谈

《了不起的我》:关于「改变」的心理学

强劲九

心理 读书 书籍推荐 看书

Redis(一)分布式缓存的作用

奈何花开

Java redis 分布式缓存

架构师训练营第四周学习总结

fenix

架构师训练营第四周作业

子豪sirius

Week4  互联网系统的技术和手段

TiK

极客大学架构师训练营

【架构师训练营】第四周总结

Mr.hou

极客大学架构师训练营

【架构师训练营】第四周作业

Mr.hou

极客大学架构师训练营

区块链技术打通信用壁垒赋能租赁业务

CECBC区块链专委会

去中心 区块链技术 防篡改 去信任

架构师训练营 No.4 作业

连增申

Week 04 学习总结

卧石漾溪

极客大学架构师训练营

架构师训练营 - 第四周 - 学习总结

韩挺

第四周作业

胡江涛

极客大学架构师训练营

互联网架构演化

李广富

程序员如何提升自己横向能力?

Boss.Guo

团队建设 能力提升 人才培养 个人总结

架构师训练营第4周作业

不谈

极客大学架构师训练营

假想 一个进销存软件是如何发展的

不在调上

第四周总结

不在调上

大型互联网系统使用的技术和方案

李广富

架构师训练营-week4-作业

晓-Michelle

极客大学架构师训练营

架构师训练营 - 第四周 - 作业

韩挺

Python中的浅拷贝和深拷贝

王坤祥

Python 编程 计算机

本周的一些总结

Geek_zhangjian

架构师训练营-第四章-学习总结

而立

极客大学架构师训练营

「架构师训练营」学习笔记:第 4 周 系统架构知识

Amy

学习 极客大学架构师训练营 第四周 系统架构知识

架构师训练营 Week 04 总结

Wancho

可复用架构之分离关注点

松花皮蛋me

java面试 Java 分布式 可复用架构

第四周作业

王鑫龙

极客大学架构师训练营

互联网架构总结

Lane

极客大学架构师训练营

Mybatis执行过程源码分析

编号94530

Java 源码分析 mybatis

大型互联网应用系统技术方案

Geek_zhangjian

要用发展的思路推进技术建设和落地-InfoQ