要面向工资编程。

虽然我不是管理者，但我觉得楼主做的没毛病。最好的办法还是协商解决。既然协商不了就按法律法规执行。

@lvangtao 难做的才有价值。而且你也有自身的优势。

个人觉得，在医院这个领域工作这么多年，你对于 HIS 系统的业务会比较熟悉，不如转为一个有开发能力的售前 /售后 /实施 /项目经理，这样不会浪费你在这行业的经验。这样可能会是个比较不错的选择。
纯技术的话确实不错，但是有行业经验的项目经理，也同样很好。

@lswl66 赞同。说的露骨一点，其实都是在交易。

所以必然要有联调试过程。

从几个角度来分析吧。
1 互联网公司的开发是否应该是 7*24 小时支持。
2 任何一个模块都应该至少两个人一起负责，形成互备。
3 需要一个良好的值班机制。

追求自己向往的工作，喜欢的人。怎么能叫掉价呢。

@ISSSSSSS 补充一句。其实这些都是我们不成熟的想法，未来是怎样很难预测。所以不如活在当下，每天开开心心的多好。

@oahebky
关于机器或自动化的问题，是我自己的判断得出。因为毕竟还没有大方面的普及。未来五到十年也不会发展到那种程度。但 20 年呢。那时候可能你我刚好步入 50 。而且这种趋势是越来越快。这个问题是我们百年前也经历过的，大批量的人被机器替换，被新的工作替换。而未来的趋势是被机器替换但新的工作却不够多了。这并不是唬人，这是真的恐怖。我们以现代人的角度去看百年前的工业革命中所处的人，觉得也没什么大不了的，但如果轮到我们自己……。
可能大部分人焦虑的点不在这个。
====
关于夕阳产业。一旦一个产业步入夕阳，那么随之而来的就是缩减人员编制、减少支出，谋求转型，资本去别的行业。这其中有一大部分人会失业，去开滴滴。可能只有一小部分“经验”的人会留在这个行业，还有更小的一部分人能够适应新行业，更多的人随这个行业一起消亡。仔细想一想，我国上世纪那些热门行业。石油、粮食、钢铁，你去了解下这些行业的底层员工，即使是现在依旧火热的石油行业，其底层员工的福利是逐步的缩简的。资金是可以快速的在另一个行业东山再起，但人没有那么快。
====
最后总结一下。你的思路无外乎是不管是在什么时候，都想办法让自己成为强者。这个思路是无比正确的，君子自强不息。
但我想反问一句，如果世上人人都是强者，那么强者又是什么，强弱只有通过对比才能提现。

====
现在的 AI 可能只是高度自动化的 AI，但一旦真正的 AI 被研发出来，人类的社会将会发生前所未有的巨变。
====
我应该不会再回复了。不过很高兴跟你讨论这些事情。

@oahebky 赞同你最后的结论。
======
至于焦虑的问题，看人。比如我就是一个乐观的悲观者。及时享乐、活在当下。
======
机器人的问题，你核算的数字太过简单。机器会随着时间成本曲线由于做工材料等成熟度越来越低，但人会越来越高。初期只能替换简单的工作，未来肯定复杂的工作也会被替代。并且这种趋势会越来越快。
======
你说的是个例。确实有很久以前的东西传下来，并且还在使用，但已经不能称之为一个高薪有前途的产业。而会变成夕阳产业。夕阳产业的薪资你可以考虑下。举个例子，石油工人或其他行业的工人。在工业时代绝对是社会的支柱、中产阶级。但现在信息时代，你觉得以这样的薪资能称之为中产么？还有就是开滴滴什么的虽染有工作，但是难以维持以前的收入水准。比如你现在月薪 5w，突然想到未来的某一天不得不去开滴滴送外卖，正常人都会有些焦虑。
======
我觉得至少国内百分之 90 的技术人员没有技术追求，所以也不会成为专家。如果有大批量的人成为专家，那专家还是专家么。这有点内卷化的意味。

我觉得焦虑有几点吧。
1 就业竞争。我国人口基数大，每年毕业人数也多。所以对各行各业的就业都有冲击，而 IT 行业冲击尤为大。毕竟这个行业一定程度上资历不是那么重要。
2 在资本驱动下，技术革新速度过快。毕竟能够掌握住“核心”的开发人员是少量。大多数人编程跟使用 word excel 没什么本质区别。突然有一天这些工具不再成为主流了，就很难维持住现在的工资水平。
3 跨域打击。比如云服务干掉了许多原来传统行业的工作。
4 资本逐利。比如云服务效率高，所以不需要聘请太多的人，机器替代人类。从资本的角度来说，我有一天 24 小时不用休息的机器，干嘛要招人呢。而且这一点比如 AI 的发展，未来 20 年必有巨变。大量的传统工作被替代，想想都恐怖。恐怕到那个时候不仅仅是 IT 人的恐慌了。

在薪资，其他比如沟通能力，双商等一致的情况下，我会招技术高的。
我巴不得我的手下个个都超过我，这样我能有更多时间不去做那么细节的事情。我的精力会逐步的从向下管理，转为向上管理。
但有一点，自己的大局观要强。

PS+Switch+PC 完美组合。

@hanhan13 补偿机制的话其实就是个业务。
具体问题具体分析。比如说 2->3 的过程。
如果是通过 mq 的方式去处理，那么会面临一下几个问题。
1 MQ 没发出去。2 MQ 发出去了，但是丢了。3 MQ 服务挂掉。4 处理 MQ 的应用发生错误。
那么最终会反映到数据存上的状态不一致。比如服务 2 有数据 但是服务 3 没数据。或者没处理。
比较简单的补偿，其实就是让服务 2 重复发送 MQ，但是也存在一定的问题。
比较高级的处理方式是，直接监控服务 2 、4 的 binlog （或者是其他数据库的 log ），通过 binlog 去比对，如果发生不正常的情况（比如状态不一致，数据丢失），那么再去处理。补偿的同时也要考虑到重复补偿的问题。
当然即使做到万全准备，还是可能会出现问题。那么这个时候就需要定时程序去核对数据。避免资损。

@hanhan13 2 ->3，3->4 的过程 可以存在事物也可以不存在（假设数据已经分片）。但我更倾向于使用生产者消费者模式去解决。比如用 MQ，再通过补偿机制去核对补充。
总之所有的都是通过最终一致性的思路去设计的。所以并不需要强事务。

@lewis89 对，其实这问题比秒杀要简单。题里的关键的锁是在用户支付后更新主播的余额。而秒杀是购买的那一刻就有资源竞争。前者主播的余额显示不及时其实问题不大，最终一致就可以了，但是后者如果用户无法下单支付就显得十分严重了。解决此类问题其实就是不断的把请求分片。不管是 nginx 还是 mysql 。

@ISSSSSSS 补充一下，如果条件限定在 mysql，那么就可以考虑 mysql 多主多从多数据源。重写数据访问中间件，直接按照用户 id 规则去访问不同的数据源。