买个电视 在家躺尸应该幸福感能高一些

IT 运维的定义是啥？纯 IT 的话没要求那么多 能修电脑就可以了。运维加上一个修服务器完活~~

@panbeta 你是在推荐从入门到放弃的通用教材吗？按照现在社畜的工作强度，能弹完小汤姆森就算不错了（狗头逃

@lastwhisper999 别着急 下一步车尔尼还有很长的路呢 846 599 299 740 巴拉巴拉~~~

没去过的可以去看看，然后就知道下次去不去了。
PS 这几年会场会多了很多漂亮的销售妹子。恩，这在 10 年前是不存在的。

另外，如果是房东的琴，还要确认你能弹多久。不然沉没成本还是挺高的，毕竟钢琴搬不走，而你的时间却是真真切切的投入进去了。

学之前 建议先把琴调一下。当然 如果你听不出来琴严重跑音的话，建议就别学了，毕竟弹琴是一种表达。乐理和技术可以通过练习来弥补。但乐感这东西提升起来真的很慢。甚至比技术挫败感还高。

@oldboy627 那这个其实就是为了保留以前的 10%的需求，而需要花费 90%的成本来实现了。（技术没有什么不能被实现的 逃。。。
而且也是一个不顾新东西的使用场景，不愿意改变既有的操作习惯。既要又要的问题。如上所说，技术上应该可以实现，但成本可能比较高。比如双写，比如改造 kibana 的界面，比如自研。。。。
不过，这些留给贵司的架构师自己评估吧。已经超纲了。

“查看对应的 trace 的时候，可以跳到对应的日志中。”最终要实现这个吧？这个的描述有点模糊。比如说是点击 traceid ，直接打开一个 url ，然后跳转一个新页将含有这个 traceid 的日志都显示出来？还是在一页里自动现实？响应速度要多少？技术实现有很多，估计症结在于“开发可以还像以前方式去查看”这个卡点。

@oldboy627 这个用 ES 筛选一下就好了啊，为何执着于 ES 的索引？你们的架构师只管提需求不去管落地技术实现吗？

@Frankcox 旧服务的静态资源先不要下掉，一般来说这种小文件放到 s3 或者 cdn 上也花不了几个钱。除非有洁癖 哈哈哈。前端的版本控制和 hash 可以搜索下，网上一般有介绍。大多数是不用自己写，前端打包的时候根据 git 的相关信息自动生成的。

@lasuar 根据他给我的回复，问题好像就是前端。但是前端的静态资源 HTML 里使用了并没有区分版本，使用了同样的资源。就产生了他的那个问题。

@lasuar
@Frankcox
所以 我还是推荐版本控制或者 hash 的方式。不管是 ingress 还是 ALB CGE 甚至 nginx 让其干一件事即可，别把全村的希望都寄托在他们身上。不然最终绕了一大圈，提高了故障率和成本之后 ，还是要自己解决。别偷懒，迟早要还的。一次两次可能还凑合，但是第三次一定让你都还回来的。

@Frankcox 如果前提是没有做 version 的话，那就耐心的等待缓存到期或者全量发布完之后？我是感觉不应该用服务端的粘性会话去处理这个场景。如果 A 和 B 这种状态要长期存在，还是用一楼的方式比较好。或者四楼的那种“粘性会话”的方式也是不错的选择，这些都是业务侧可控的。而运维侧负载均衡提供的“粘性会话”是比较危险和不可控的，不太建议。以上不分前端后端的一个大原则。

不说后端 就是前端的话 。请求到新的 HTML 最好里面已经告诉浏览器去加载新的静态资源（ version 为新的）。这就又回到 version 控制（ hash ）的问题上了。反正就是自主可控，虽然很繁琐，但打包发布工具这时候就有作用了。如果坚持不用 version 或者 hash 的方式话。上了 CDN 你又要找其它的“粘性会话”方案了。并非一劳永逸。

说一下你需要的网线等级以及期望值，然后再说期望花多少钱比较好回答一些。宽带师傅一般可以帮你顺手打一下，不过别期望太高。超六和七类线有些宽带师傅也不一定能搞定。甚至有些师傅连测线器都不一定带（上次给我装的师傅就是，光纤已经不咋用那个东西了）。 所以 工具可能还是需要自己备着。

想问下，这种的情况不是应该返回新的静态资源版本吗？例如 http://domain/a.png?v=123 灰度只灰度了后端，前端最好也同步控制。而不是用粘性会话来解决。粘性会话感觉更合适的场景是后端“异常”的时候的方式。

如果是单身的话和爸妈一起住还怎么找妹子啊？狗头

感觉应该是非市政道路应该就可以，非市政道路的执法权好像不归交警管理。

哪里办的？