开篇词 | 学会如何工作，和学习技术同等重要

作者回复: 哈哈，有钱的捧个钱场，没钱的捧个人场～ 不过我专栏里也会提到，我真心不建议裸辞，很被动的。哪怕你再不喜欢老的公司，也骑着破驴找新马。裸辞的话，一方面新公司可能会因此“压价”，另一方面新公司也会在意这个事情，想知道你裸辞的原因。我的建议是你想好一个自己裸辞的理由。 当然，有一点好处是，你的入职时间可以很快。有时候也是很重要的一个优势。这些都要看机遇，随缘。

作者回复: 嗯呐，软件行业发展这么多年，单兵封神的时代基本过去了。 努力做专栏，努力不让你失望。有问题也欢迎你在相关章节里留言讨论～

作者回复: “不是我不努力，而是别人分配你的活根本就无法锻炼你。” 这个我同意。。。外包和外派我在这个专栏里会讲到。

作者回复: 事情都做完了，被卸磨杀驴，如果我说我不是第一次知道这种事情，你会感到惊讶么？这也是我为什么在直播选题的时候，会强调找个合适自己的经理。 专栏里也有一篇说这个事情，很多人觉得某个项目机会难得，哪怕经理奇葩，也忍了，先做事。但是很多时候这种情况下，做事儿的程序员就算做成了事儿，也没有收益。

作者回复: 嗯呐，我觉得第一步是认同交流沟通的价值，然后结合自己实际的情况，选择合适的处事方式。如果自己可以，那么自己来，如果自己不大可以，那么可以借助别人来。

作者回复: ✅✅，选择在专栏里也有重点提到。经历过的都懂，我想通过这个专栏，帮助没经历过的、正在经历的、经历了也没懂的同学，懂。

作者回复: 我的感觉是，任何改变，都是个需要出很多的过程，更不用说转变。尤其是在工作中，日常繁杂琐碎的事情很多，如何能不被这些事情耗尽精力，进而有机会做自己想做的改变，其实真的是一个挺难的过程。 我有个朋友也是做运维的，也是想转开发（真的。。。真的不是无中生友。。。）。他也是传统金融行业，并非是互联网行业，没有对运维工作提出太高的要求。我跟他聊下来，给的建议是从日常工作入手，看看有没有机会做个项目，替代日常繁杂的工作。哪怕是自己用业余时间做。 如果公司对运维的依赖和重视程度很高，比如说互联网公司，那么不妨专注于运维，让自己的开发服务于运维。比如前面我提到的，可以让自己的运维范围从一台台独立的机器，慢慢上升到机器上跑的服务指标，再上升到服务所支撑的业务指标 其实，很多做开发的，也是困扰与自己是业务翻译机，十年专注CURD，觉得自己会的东西太窄，都是围城。

作者回复: 运维方向没有深入了解过，就我接触到的信息看，有两个方向。 一个是紧跟业务，为业务提供价值。很多运维从传统的机器层面的运维，利用自己的监控系统，讲业务监控和运维纳入自己的范围。比如说，之前是监控机器的健康信息，慢慢的将机器上部署的服务，服务所属的组，也纳入到自己的信息系统，机器出问题，立刻给相应的组上报。更进一步的，将业务的指标也纳入监控系统。也就是说，监控的不仅仅是机器健康，而是业务健康，比如订单量，浏览量等等。这样，可以为业务提供价值，尽早发现问题，减少损失。 另一个方向是智能运维，提供根因分析，这个是比较技术流的，对技术系统要求比较大。 运维有一个优势是掌握着机器的健康数据，而且缺省就需要轮值，既然轮值监控，为什么不更进一步，监控更有价值的业务数据呢？

作者回复: 是的，程序员要一直提升自己，而提升自己只靠技术是不行的。 关于解决线上问题，经理不知道，确实有点憋屈的感觉，又累，经理还不知道，找谁说理去。。。这个一方面可以在 1:1 会议上说说，如果你觉得线上问题对你来说是个很大的包袱，可以让经理考虑是否别人可以分担一部分。 但是就我自己的选择的话，我会选择将生产问题扛下来。这样你可以对系统（自己的系统和公司的系统）更熟悉，虽然短时间看，自己是“吃亏”的，但是如果你打算在这个公司长期发展，其实对你是有利的，也许经理一次两次看不见，也不会每次都看不见。而且和你合作的人也能看得见，如果你的人设是“能搞定问题的那个人”，你的付出就有回报了。 当然，线上问题，解决是一方面，另一方面是总结，然后向经理提出如何进一步避免问题的方案，这才是向前迈出了一步。如果只是每次被动上去解决，确实不能带来很大的成长。

作者回复: 略有一些，略有。 你知道Sybase被SAP收购了，想必也是混张江的了😜