|
本人就从Java角度来说，其实技术加运维是一条非常好的上进之路。 先来看看运维平时的工作及需要掌握的技能。 1 监控日志，而日志一般是部署在linux上的。如果出错，需要告知开发来解决，如果比较上心的运维，出了问题，更会通过linux命令来分析日志排查问题。 2 部署上线组件，比如要扩容，或者部署redis，nacos等组件，或者需要部署云端组件。在这过程中，运维多少会了解各种linux命令，而且了解各种组件的配置方式以及安装方式。 3 部署监控，比如用newrelic监控，或者zabbix等监控软件来监控，并设置告警策略。 4 应对线上问题或高并发的挑战，这过程中，不仅需要了解各种集群，更有机会熟悉各种网关和负载均衡等的硬件。如果数据库或服务器有问题，更得通过日志或监控组件，分析和排查问题。 5 其实运维还能接触到devops的相关技能，比如pipelines，云部署，甚至是k8s和service mesh这套技术。 从Java角度来看，架构师要做的事情有哪些？ 1 根据业务场景，用nacos，gateway或ribbon等组件搭建业务框架，必要的话引入redis，kafka等中间件，甚至有必要的时候再搭建集群。当然搭建好以后，相关组件有什么问题都需要解决。 2 负责项目上线和数据迁移这部分的工作，比如设计发布流程，编写发布脚本，设计发布预案，设计数据迁移等的方案。 3 解决各种高并发方面的问题，比如引入各中间件，再通过压力测试确认系统的承压能力和改进点，必要的时候设计限流熔断等问题。 4 系统上线后，需要搭建针对系统的监控系统，有问题以后需要及时排查。 也就是说，架构师的工作其实很大一部分是和运维是重叠的。而当下不少程序员做的仅仅是单机版的增删改查，开发环境仅限于windows，而不是linux，更别提是容器，中间件这块仅限于使用api，不涉及如何搭建中间件以及集群，解决问题层面仅限于解决业务问题，如果中间件或底层遇到问题，基本上估计连异常信息都看不懂。 这样大的程序员不在少数，有的甚至还会排斥运维或架构方面的技能，或者说在平时工作中仅仅做业务，没机会掌握一些运维方面的经验，这也是很多程序员无法上升到架构师的原因所在。 当下，一些大厂在招人时，除了会spring boot等框架的增删改查经验外，更得会分布式高并发的经验。开发语法好学，部署等经验难学，排查分布式高并发等线上经验更难学。 所以运维做了1，2年以后，只要稍微了解下Spring Boot等方面的语法，甚至就能直接升级到架构，而且不少运维还不知道自己掌握的技术很值钱。当然，如果运维对自己定位不当，或者公司对运维的使用不当，导致运维平时只干些装电脑装软件等工作，这就另当别论了。 下面就说说本人知道的运维高效升级到架构的一些例子。 1 就说我自己吧，我之前在一家公司，虽然做的也是增删改查，但由于和一些运维也比较熟，平时也耳渲目染了一些部署和调试方面的技能，虽然没有得到实际的操作机会，但自己感觉已经比单纯做开发的程序员要好很多，不仅掌握了不少linux部署组件和排查问题的相关技能，更熟悉了一些分布式组件和集群的搭建和运维经验。后来我跳槽，这些经验也帮了我很多。 2 我见过一个2年经验的运维，平时干的活很累，要维护多个项目是常态，但当他自己补了一些spring boot技能后，直接进了一家大厂，据他自己说，大厂面试虽然会问一些高并发中间件，但他平时都实际安装和操作过，所以基本没问题，然后薪资翻番。 3 我见过一个专门做部署的运维，可能业务不熟，但很熟悉devops这套，什么k8s配置部署都很熟悉，后来也进了大厂。 所以其实可以这样说，掌握业务技能不难，掌握单机版的增删改查技能也不难，做熟了增删改查工作，从使用中间件的API慢慢熟悉中间件，然后再进一步掌握中间件的搭建以及排查问题的技巧，这其实是一条路，而如果直接从运维角度入手，一方面熟悉lunix等操作命令，另一方面直接和中间件、集群乃至容器等打交道，这条路其实更能方便提升到架构。 毕竟API容易学会，而架构方面的实践机会难得，所以这方面的技能反而是更难提升。不过话说回来，如果干运维仅限于系统维护和输入参数，这就相当于程序员只关注增删改查，这样就相当于空守着值钱的项目实践机会而不提升自己，这就非常可惜了。 |
|
|
