本职工作
golang有一个特点，无需特殊优化就可以轻松榨干多核心处理器的计算能力，实现这个特性的关键是runtime的调度器，它会根据系统核心数设置对应的逻辑处理器上限，并自动管理系统线程的创建、销毁、运行和休眠，并将goroutine绑定到系统线程上运行。
在上一份工作中，我们的部门主管大概就是那个调度器（也许是更大的执行单元），从公司层级的任务池中抽取goroutine，分配到负责执行的打工人身上，有的打工人是单核心单线程的，有的打工人是双核心四线程的。若是按照本职工作来划分物理核心，笔者大概是M核心N线程的处理器，这两个参数取决于突发问题的出现频率。
golang的runtime可以在goroutine阻塞时保存context，让出系统线程来运行其他的goroutine，而在条件满足时，则会重新调度goroutine，恢复context运行原来的代码。可惜人不是机器，我们没有那么方便的堆栈来存储context，每个经历过高考的人大概都会记得这句话：数学做累了，就做下英语、语文，换换脑子放松下，但我们都知道这只是在挑战自己的毅力和体力极限。
有经验的SRE对系统负载监控数据的尖刺都会多加关注，遇到系统负载超出上限，通常先走完扩容、限流、排查一条龙操作，不会放任不管，而笔者遇到的是：多开线程，切换上下文......可能老实人并不适合这份工作，笔者的组长也是经常说要尽量把简单的任务推出去，专注在解决难题上，他自己也被压得喘不过气。
笔者的一位朋友最近也是遇到了类似的事情，他历经磨难从互联网打工人转换为事业单位打工人，原本就是带着逃离996的目的入职的，可惜遇到了一个正处在事业上升期的领导，这位领导和他的几位同事是同一时间调到当前单位的，几年过去，其他人还在躺平，他却已经升上一级，并且还在继续冲刺。
这位领导不分份内份外接活的做法让我感到莫名的熟悉～凡是上级领导要求的都执行，除了自己部门的业务外，又承接兄弟部门的活，当自己做不完时，就把工作分发给手下，手下的人也做不来时，就需要加班，或者拜托其他同事协助，欠下人情。
但笔者的朋友是经历过996洗礼的高纯度混子，他是能拖则拖，或者绕着弯子拒绝，几番下来，没想到开会时突然被领导集中火力批评了一顿......虽然他被批评的时候有点慌，但会后一个老员工安慰说不需要过度太紧张，并给他捋了捋逻辑，大概是这样的：
- 他并不是摸鱼，自己的本职工作是有完成的，同时也抽空帮忙处理同事手上的急事
- 有些工作只适合这位需要晋升的领导的去做或者去推动，才合情合理，普通小兵插手他人事情容易遭到白眼
- 一旦做过某件份外事，被当成接口人，后面就会有源源不断的人找来，占用大量工作时间
- 如果被份外事占用时间，导致本职工作无法准时完成，对自己的业绩影响更大
当然最重要的一点是，笔者的朋友是事业单位编制，而且存在轮岗制度，他也不求晋升，继续做好份内事即可。
论语说：不在其位，不谋其政。我想对小兵来说，在工作中应当遵守分工原则，不要擅自越权或干涉他人的职责范围，而对领导来说，这些规则可能是不存在的，他们关注的是解决问题，做出业绩，会把得力小兵安排到各种场景中去。
在上一份工作中，笔者的本职工作是负责容器云的后台开发，这是第一个核心，从这个核心衍生出集群管理、网络方案、存储方案和技术支撑，既需要写代码、又需要写大量的手册和文档，而问题处理的多之后，才发现容器产品并没有SRE？？？；SRE成了第二个核心，俗称运维，服务升级、问题排查、业务上云、POC、出差这些乱糟糟的东西占了许许多多的精力；由于同事离职，导致维护DevOps团队镜像仓库这个烫手山芋也到了手里，这是第三个核心；还有一个基于OpenShift Container Platform改造的PAAS平台项目，给笔者造成了不小的心理阴影。
这里的人力资源管理像是实现了抢占式调度～没有最重要的事情，因为所有事情都重要，只有最紧急的事情，因为紧急的事情经不起等待～这就导致我们的工作总是很容易被中断挂起，其他部门也是彼此彼此，有时候上周还在和A同学对接，下周就换成了B，问A的去向不是有紧急的任务，就是离职了。
工作不是短跑比赛，而是一场异常漫长的马拉松，记得最开始入职时，就有一位同事生病主动离职，当时笔者还在想自己该不会也是这么收尾吧🤣，在往后的日子里，那些加班得最猛的同学在流感和病毒侵袭时也是倒得最快的。如果既要做好本职工作，又得要完成额外任务，那么保住工作和保住健康只能选一样了。