场景

以项目经理身份，驻场开发兼运维，其中苦乐自己体会。

笔记

做运维工作需要会什么

1、熟悉业务流程，出现问题很快提供解决办法。 (这个要多学习，多记录，多总结)
2、熟悉常用的页面操作。(不解释，必须熟悉)
3、会用常用接口。(查询接口，以及简单的改动接口)
4、如果会sql就更好了，并知道常用业务之间的数据库关联。(数据库权限好像一般不给运维啊)
5、熟练使用excel表格。(哈哈，各种汇总工作)

痛点

无堡垒机权限

公司是相对较大的公司，管理严格，开发运维人员无堡垒机权限。而是在甲方公司的直接领导手里。 每次登陆都需要找人家要验证码，头大。

无数据库权限的弊端

虽然有接口，有页面，但是能够处理的事情比较有限。数据库更灵活，信息最全。 无数据库权限，相当于砍了一条臂膀，非常不顺手。

码在别人手里的弊端

堡垒机+验证码 才能登陆数据库。
码在别人手里，每天都要找人要码头痛不头痛。木有人愿意光麻烦别人，所以能少要就少要，能不要就不要。
堡垒机session时长1小时，忙起来没刷堡垒机页面session没了有木有，吃顿饭回来session没了有木有，再找别人要码? 算了，不急的话，明天吧。 幸亏后来找了个自动刷session的工具，稍微缓解了些。
公司开发有一套vpn，驻场有一套vpn。因为开发和运维要兼顾，如果不忙了，抽俩小时写开发代码吧，不行额。切到公司vpn，再切回现场vpn，堡垒机没了… …。 所以白天不敢写代码，晚上下班了，不用处理运维问题了，抽时间追赶下进度。

如果码在自己手里方便很多，我重新登录下就行了。

开发和运维兼顾

招的时候，是当项目经理来招的。说是项目经理，其实就是几个项目都归你管。 开发，运维问题都要处理。
客户报上来的问题，有不少是需要查接口，查库，看日志才能定位问题的。
随口解答的问题不说了。 如果是需要查东西的问题，一天有十个八个就会感觉到很忙碌。
而且还要顾及开发，好在因为运维的存在，开发排期相对宽松。 因为怕分心，我都是晚上，早上写代码，白天处理问题。

这里也容易造成死循环。 就是感觉某个地方有漏洞， 想要下力气解决下。 但是一堆问题处理完毕，已然晚上10点，11点了。 心力交瘁，哪里有余力优化。 然后明天继续疲于奔命的四处救火。 一点一点漏洞积累起来，终于不可收拾。

所以建议运维和开发还是分开比较好，专注一事更有效率，而且这样配置资源其实性价比更高。

子系统太多运维问题处理不过来

甲方虽然只是一家公司，但规模较大，子公司七七八八，少说有大几十家。 那么多公司，问题肯定少不了。 你想今晚熬夜把所有问题处理完，明天轻松点? 明天还有大把问题等着你。 所以抓要紧的问题处理吧。

此前，周一上班就盘算双休去哪溜溜，现在别想了，先想想到晚上11点还有几项工作需要做… …。

各种周报

日报周报不说了，一般公司都有这个机制。还是有它的必要性的。
驻场周报还是有点不一样。

甲方周四周会，周三要总结周报。
综合管理每周一周会，周五要总结周报。

好吧，本公司日报，周报+甲方周报+综合管理周报。 感觉很多报啊。

群公告

群公告是个折磨人的活，主要是发出的东西需要负责。
做多了运维磨炼出一堆稳妥或甩锅的本领。
这里记录几个公告，便于复用。

案例一：

【变更公告】
各位好，将在【2月28号18:00-3月1日8:00】升级【用户中心】，升级期间将【影响】用户中心【用户管理】功能，升级后不影响周边系统业务；

具体时间届时将及时通知，给您带来的不便，请谅解，升级期间如有问题可联系zhangsan，感谢！

其他

工作记录

这个还是很重要。
一方面可以记录工作中处理的问题，有利于总结。
另一方面领导问起最近做了哪些工作，可以很快的汇报。 否则，2个月前干了什么活，谁能记得?

成长性

大公司有一定的好处，就是他们的机制，以及概念，至少你会接触很多。
例如岗位的分工，各种角色，安全管理，dba，业务，产品，项目经理，开发等。让你知道并不是开发才是唯一的岗位。 各个岗位都能挣钱，开发最辛苦，而且待遇绝对排不到前列。 说白了，只是技术工的一种。

例如数据库集群，redis集群，项目至少也得用个spring cloud吧等。 以及短信，邮件，mq，配置中心，密码加密，网络网关等的管理。

其实如果做的久还是有一定成长的，前提是有时间总结并提高自己。

忙与成长

忙就会成长的快么?
不一定，要看情况。

如果每天都是接触新事物的忙，或者不断深入的忙，都是很好的。接触新事物是宽度，深入研究是深度。收获多少且不说，见识肯定增长。

任务下的开发和钻研性的开发哪个印象深刻?
老实说，迫于任务的开发印象深刻的多。 笔者没事也爱东看看西做做，弄些demo来做。 做了很多，很多即使做过，慢慢也淡忘了。
但是如果是任务驱动下的开发，那么印象会比较深刻，一想起这个知识点，就想起当初这个任务怎样逼的自己绞尽脑汁，夜不成眠的想办法了。

事情繁琐的忙？
这项工作子公司太多，客户就更多，各种问题都要找你，很多都是非常基础的问题，但是客户一点都不懂。 你刚要做什么事情，就插进来个客户来找你。 要专心搞什么东西，想都别想了。 一门心思想把事情做完，就轻快了，想都别想，还会有更多的事情来找你。 想抽时间学习下，研究个知识什么的，一天下来筋疲力尽，哪还有精力搞这个。
这样的工作，在经济寒冬可以作为暂栖之地，不利于长久发展的。

如何面对一头包的工作

每个coder都有这样的经历。 接手代码后发现设计不合理，代码凌乱不堪，隐患重重，指不定哪天就出什么大事情。 整日战战兢兢，如履薄冰，甚至都不想干了。
其实大可不必，项目比较棘手这样的情况太常见了。 要知道，即使换个岗位，还可能遇到烂项目。 要做的就是全力以赴，看看到底能撑多久。 过程中肯定会遇到很多艰难，但是这就是成长啊。无论体验是否好，这都构成你轨迹的一部分，如果因为搞不下去而离开，那么多失败啊，说起来就是因为能力不行而离开，这多不好。但是如果你浑身解数，攻坚克难，周旋了许久，最后离开，有没有一种功成身退的感觉，日后回忆起这段峥嵘岁月，你都会被自己感动的。
一句话，走可以走，但不能灰溜溜的走。

生产问题的重要性

运维人员就是救火队员，火情大于一切，生产上出现问题，永远要第一时间解决，不管是否半夜12点，你是否在酣睡。
例如晚上服务挂了，你说第二天到公司再解决？ 估计会收到一火车报事吧。

严谨负责的态度

运维不是过家家，是要对项目客户对项目负责的，尤其是很多项目涉及到银行，金融。
都是非常重要的业务，容不得一点错失。

不要说误删库，误删服务器这种万死莫赎的操作。
列举下以下场景：
私自发版(重启应用) 一次严重警告，两次直接开除。
私自增删使用中的表的字段 直接开除。
私自重启服务器(不是重启应用哦) 直接开除。

任何可能造成不利影响的操作，都要谨慎，总之一切为客户为中心，为用户着想。

工作中的烦恼

无论如何，做工作总会遇到烦恼，这就对了。
因为工作的本质就是给别人干活，当然不能事事顺心，明白这个道理，可能心态就能放平和一些。
工作中的烦恼有很多，压力、劳累、技术压力、人际关系等。
这些都是正常的，也都有应对手段。
比如说面对劳累，可以适当放松，节奏不那么紧。
面对技术压力，可以针对性的集中解决某个问题等。
面对风险压力，可以做操作时谨慎一些，都按照不留后患的路子走。

注重调节，也注意保重身体(身体才是革命的本钱)。

当然，现在环境不好，方方面面的压力都很大，每个人基本都是这种状态，只能说做最好的自己吧。

注：万不得已的情况下，工作离了谁都会继续，所以不用把自己锁的太死，劳逸结合，有输出有态度达到平均水平或偏上(如果精力允许)。

恶心的流程管理

服务的公司是个大公司，这几年行业不景气，业务大幅缩减，取而带之的是内部流程管理。

关于这个流程管理的本质就是内耗。
业务快速发展的时候，一定不会有复杂的流程管理，因为影响效率。
当行业不景气，需要控制成本，大量做业务需要花钱负担不起，但是这波人怎么办呢?
总要做些事情吧，要不白吃饭，那就弄流程管理吧，控制发版，流程复杂化，一分的活九分的流程，不就有事情做了吗?饭碗也保住了。
但是从服务方就很难受，本来是活干完完事，一分的活签一分的合同，现在还是一分的活，能签十分的合同?难道能说我写文档，写用例，走流程，做各种非必须的工作花了很多时间吗?客户也不会认。
真心被恶心到了，简单的说你们内部愿内耗随便，没人乐意陪你们。
脑残的流程管理。

2025-03-11 再次被流程管理恶心到

发个版，要变更文档，要测试方案，要测试用例，要测试报告。
关键是同一份内容相当于写好几遍，有的就是改个简单的超时配置，例如60s改成180s，居然要写4份文档，什么傻逼思路，这需要测nm，评审的人都不长脑子的，做流程管理的是蠢猪吧。