blless 最近的时间轴更新
blless

blless

V2EX 第 241141 号会员,加入于 2017-07-19 10:59:30 +08:00
根据 blless 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
blless 最近回复了
28 天前
回复了 Stendan 创建的主题 哔哩哔哩 如何看待 2021.07.13 B 站崩溃事件
@pastor #66 能做的话都不是事,但是这种一般工作量太大了。涉及人和部门非常多,协作起来真的要命。除非整个 Ops 平台化建设都很完备才有可能这么搞
28 天前
回复了 Stendan 创建的主题 哔哩哔哩 如何看待 2021.07.13 B 站崩溃事件
本老运维出来说一点点。
核心就是 B 站对运维投入应该不够重视。几个关键字,2021 年,自建机房,OpenResty+注册中心 ,线上网络和办公网络互通,关键业务 SLB 居然还要临时新建,业务回滚极不完善。

不过也是事后 BB 罢了,线上原因多种多样。运维做多了,个人觉得核心在于不是排查出问题或者解决问题,而是快速恢复,降低影响。所以一个老运维需要很清楚知道,一些改动可能影响的范围。

这里事故的关键点其实在于,利用 OpenResty 的灵活性,接入了一个可以动态获取网关配置的注册中心。也就是说 LB 的配置变更的核心在于注册中心配置下发的配置。(我以前公司任何可能改动到网关的配置审核都是三层审核)。这里我猜很有可能 B 站注册中心下发配置权限在另一个部门,而且可能绕开了线上运维人员的审核。然后整个事故报告里面没有提到一句下发错误配置的部门,整个事故报告围绕自身问题...似乎看到了一个已经被强势业务部门 PUA 成性的背锅老运维了。所以如何把关键变更权掌控在运维手上,或者至少有效通知到运维人员,才是运维的关键。但是这一点往往因为业务线太长,需要公司更高层级的支持,所以往往一个公司的运维好坏是跟公司整体相关的。强势业务部门就会以各种理由抵制这些手段,老板也会站在业务部门角度。没有任何办法,只能等血淋淋的线上事故发生之后,趁机搞一点运维建设。

另外好多人一说事故就提高可用,问题是高可用上限是没有边界的。公司不注重运维体系建设,盲目砸钱搞高可用,本来人就不多,还要加工作量,我只能说下次事故说不定指日可待
@peter520 @29 Go gin web ,别整什么 java python 这种语法糖多的语言框架,你写一半不懂才知道要还要学会各种语法糖封装的各种组件遭不住的
后端就建议别拿后端经验去套 js , 还有先把阮一峰的 es6 教程看一下。。https://es6.ruanyifeng.com/ 本后端刚开始写前端都懵逼了,原生古早 js 跟现在的 es6 还有一堆乱七八糟的 es2005 2xxx 根本不是一回事。然后再去看 vue 吧。。
说前端混乱我觉得不是没有道理的,html css js 每个项目用的标准都不太一样,html 还是简单的,css 有各种 less sass ...js 就是什么 es6 es2005 es2015 啥的。然后框架 vue react angular 啥的,加上各种 babel npm 开发工具。。虽然写起来都不太难,但是整个体系下来感觉就是太混乱了。。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1059 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 20:53 · PVG 04:53 · LAX 13:53 · JFK 16:53
Developed with CodeLauncher
♥ Do have faith in what you're doing.