从大一开始主力用 linux ，入职现在公司发了 macbook ，试了下各种用不惯，申请了台式机，macbook 一直放着吃灰...

更新后蓝牙断连严重...

调研到了这个 https://redis.io/docs/stack/timeseries/
感觉蛮合适

"The behavior is undefined if r is negative or NaN, or if theta is infinite."
https://en.cppreference.com/w/cpp/numeric/complex/polar

@southwolf #57 上线前肯定是测试过的。但是有些部分是没办法完全测试到的，比如一个很大的变量就是模型。每个服务的模型都是不是一样的，我们一般只能挑有代表的几个模型测一测，没办法做到全覆盖。还有很多问题的根源在于权限不收敛，线上环境可以被同部门的其他同学随意变动(比如扩缩容，放量，将一个错误的模型上线到某个服务上)。 权限控制这部分就要跨部门了，我们也只能等人家的排期，转眼也等了快一年了(

@461da73c #37 公司是绿色软件家。不过看其他楼层的回复，字节，快手估计也差不多这个样子...

@Lonenso #40 感谢，我去看看，增加一些工作的信心(x

@wangyzj #46 我们部门的 SRE 比我强度还大很多...ToC 的公司基本都是 24 小时有业务吧😂

@NCZkevin #39 巧了，我们确实是做框架的组.... 快手的框架组也这样嘛，害怕

@461da73c #37 是啊，线上跑了几年了。 其实已经上线不去修改的服务也不会出问题，出问题的大部分都是新服务，比如想用某个新功能但是没配置对或者新功能有 bug. 是没有测试的，测试全都被砍掉做测试开发了。 服务质量交给开发通过写单元测试，接口测试自己保证。 测试左移算是一个大趋势吧(虽然有利有弊

@OliveGlaze #33 哈哈哈哈那确实

@wa007 #30 是呀。请求出错大部分倒不是服务的问题，而是用户代码的问题(比如请求了计算图中不存在的 tensor) 但是模型上线失败确实是组件的问题。我们依赖的两个外部存储会出问题，平均一周两三次吧。 以前次数更多一些

@xmumiffy #29 差别还挺大的，正常上班的话吃饭，午休都不紧不慢，节奏自己可以把控。OnCall 就完全不一样了...

@ZSeptember #25 1. 技术债太多了。
2. 业务方不知道是自己的问题呀，我们是调用链的下游。
3. 我觉得主要是业务招人完全不考察这方面，基本只看发了什么 paper, 所以很多业务是基本不会写代码的，问题就特别多了。

@OliveGlaze #23 如果是做 infra,哪里都逃不过 oncall 的，国外也一样😂

@ryd994 #22 老哥说的都非常有道理。 我老板还是靠谱的，也在想办法解决。 但是一个是人力原因，一个是技术债实在太多了，公司各种古老的技术架构也在慢慢更新。 我尽力而为吧

@marffin #13 我们这边的要求是，如果能明确是某个人写的代码的问题，那么可以交给那个同学来处理。 但是时间主要就花在定位问题上了。对于问题的定位，我们这边一般是哪周出现的问题，那一周 oncall 的同学跟到底。 然后我这边其实已经都是白天了，基本没有晚上处理的情况. 但是单子还是处理不过来

@d5 #9 研发 on-call 基本只有白天，而且我也不是外企哈哈哈，木有其他时区的同事

@Biggoldfish #10 学弟现在在哪家来着。 我们其实不算直接 customer facing , 但是因为是推荐场景，服务有问题就直接影响算法效果。 感觉做 infra 的话去哪里都少不了 oncall