DevOps 和 SRE

最近有一位朋友和我聊职业发展方向问题,聊了不少 DevOps 和 SRE 话题。 我几年前刚接触这两个概念时也常常将之混淆,可惜当时没有人来解答我困惑。 现在这虽然已经极为流行,但是我发现我这位朋友对这两个职位还存在一些误区。 于是我给了一些见解并整理成文章以饕大众。

最常见的误区:

  • DevOps 新概念,好高级哦
  • SRE 是高级版 DevOps
  • 运维可以轻松转身 DevOps 工程师

让我一一给你讲解吧。

sre-and-devops.png image via YouTube

more ...

破解三才五格姓名测试

201807/bagua.png image from Wikipedia 八卦

随着孩子预产期临近,我还有一个重要的任务没有完成:给孩子起一个名字。 这本来是个随性的任务,但是由于上一辈笃信某个算命先生的姓名测试算法,让这个任务难度倍增。 我根据一些古文取了不少名字,但是最后都败在姓名测试上面:得分不高。得分不高老一辈就要有说辞, 我自己就是一个活生生案例,曾用名得分不高,中考被逼换了名字,改头换面重新做人。

我根据韵律取的名字几乎都败在算分数上面,我得琢磨一下其中奥秘,提高取名效率,避免再出现差错。 不少网站都提供姓名测试算命,我且先看看上面的得分,研究一下规律:

每家网站都写得天花乱坠:易经、五格剖象法、五行起名、五格起名、三格数理。 这些都不用 Care,因为它们都是来自同一个算法:「三才五格」。

more ...

从 SQL Server 到 MySQL(三):愚公移山 - 开源力量

201806/refactor.png

我们用了两章文章 从 SQL Server 到 MySQL(一):异构数据库迁移 / 从 SQL Server 到 MySQL(二):在线迁移,空中换发动机 介绍我们遇到问题和解决方案。 不管是离线全量迁移还是在线无缝迁移, 核心 ETL 工具就是 yugong。

Yugong 是一个成熟工具, 在阿里巴巴去 IOE 行动中起了重要作用, 它与 Otter / Canal 都是阿里中间件团队出品。 它们三者各有分工: Yugong 设计目标是异构数据库迁移; Canal 设计用来解决 MySQL binlog 订阅和消费问题; Otter 则是在 Canal 之上,以准实时标准解决数据库同步问题。 Otter 配备了相对 yugong 更健壮管理工具、分布式协调工具, 从而长期稳定运行。Yugong 设计目标则是一次性迁移工作,偏 Job 类型。 当然 yugong 本身质量不错,长期运行也没问题。 我们有个产线小伙伴使用我们魔改后 yugong, 用来将数据从管理平台同步数据到用户前台,已经稳定跑了半年多了。

more ...

从 SQL Server 到 MySQL(二):在线迁移,空中换发动机

flying-tanker

(image via https://pixabay.com/en/military-stealth-bomber-refueling-602729/ )

在上篇文章 从 SQL Server 到 MySQL (一):异构数据库迁移 - Log4D 中,我们给大家介绍了从 SQL Server 到 MySQL 异构数据库迁移的基本问题和全量解决方案。 全量方案可以满足一部分场景的需求,但是这个方案仍然是有缺陷的: 迁移过程中需要停机,停机的时长和数据量相关。 对于核心业务来说,停机就意味着损失。 比如用户中心的服务,以它的数据量来使用全量方案,会导致迁移过程中停机若干个小时。 而一旦用户中心停止服务,几乎所有依赖于这个中央服务的系统都会停摆。

能不能做到无缝的在线迁移呢?系统不需要或者只需要极短暂的停机? 作为有追求的技术人,我们一定要想办法解决上面的问题。

more ...


从 SQL Server 到 MySQL(一):异构数据库迁移

201803/migration-bird.png

背景

沪江成立于 2001 年,作为较早期的教育学习网站, 当时技术选型范围并不大: Java 的版本是 1.2,C# 尚未诞生,MySQL 还没有被 Sun 收购, 版本号是 3.23。 工程师们选择了当时最合适的微软体系,并在日后的岁月里, 逐步从 ASP 过度到 .net,数据库也跟随 SQL Server 进行版本升级。

十几年过去了,技术社区已经发生了天翻地覆的变化。 沪江的技术栈还基本在 .net 体系上,这给业务持续发展带来了一些限制。 人才招聘、社区生态、架构优化、成本风险方面都面临挑战。 集团经过慎重考虑,发起了大规模的去 Windows 化项目。 这其中包含两个重点子项目:开发语言从 C# 迁移到 Java, 数据库从 SQL Server 迁移到 MySQL。

本系列文章就是向大家介绍, 从 SQL Server 迁移到 MySQL 所面临的问题和我们的解决方案。

more ...

从 2017 到 2018

2017 年 2 月摄于瑞虹月亮湾

(2017 年 2 月摄于瑞虹月亮湾)

我有两年没公开年终总结了,原因很简单:年终结果无法让自己满意, 生活持续呈线性发展。那今年为什么又要将总结发出来呢? 并非是我的 2017 过得如何充实、有成就感,而是出于两个目的。 第一是我认识到 OKR 需要平和对待,我目前对自己的生活是缺乏完全掌控力的, 我无法既渴求爆炸性的增长,又期望在这一过程中低风险,我需要接受这种现状。 第二是曝光自己的目标,让回顾和计划透明化。 从社会心理学的角度上来看,公开的承诺有助于个体更努力地驱动目标的完成。

more ...

工作和热情

201712/work.jpg

最近和一位老朋友吃饭,他说他最近比较苦恼: 「开始有职业危机了,担心自己失去对工作的热情,似乎离油腻的中年人又进了一步」。 作为一名互联网工程师,我深知这个行业技术日新月异, 如果对工作都失去了兴趣,会将自己置于跟不上时代发展、自身得不到提升的危险境地; 从个人生活质量来看,工作占据了一天 1/3 ~ 2/3 的时间, 失去热情的工作会成为人生的桎梏,不是驾驭工作,而是被工作所奴役, 这会进而影响一个人的身心健康,得个抑郁症稀疏平常。

如何保持对工作的热情,当自己陷入困境时候如何重新调动工作热情? 这是职场人需要深思的问题。

more ...

服务性能监控:USE 方法(The USE Method)

本文首发在沪江技术学院公众号,小莞翻译,我做了校对。 由于微信公众号的封闭性,我担心未来文章不容易被发现。 为了避免沧海遗珠,特意转到这里。

英文原文:The USE Method


201711/performance.jpg

USE 方法是一种能分析任何系统性能的方法论。 我们可以根据能帮助系统分析的结构化清单,来迅速的定位资源的瓶颈和错误所在。 它通常会先以列出问题为开始,然后再寻找适合的指标,而不是给你制定一些固定的指标, 然后让你按部就班的执行下去。

more ...

Stack Overflow 的 HTTPS 化:漫漫长路的终点

Stack Overflow


今天,我们默认在 Stack Overflow 上部署了 HTTPS。目前所有的流量都将跳转到 https:// 上。与此同时,Google 链接也会在接下去的几周内更改。启用的过程本身只是举手之劳,但在此之前我们却花了好几年的时间。到目前为止,HTTPS 在我们所有的 Q&A 网站上都默认启用了。

在过去的两个月里,我们在 Stack Exchange 全网维持发布 HTTPS。Stack Overflow 是最后,也是迄今最大的的一个站点。这对我们来说是一个巨大里程碑,但决不意味着是终点。后文会提到,我们仍有很多需要做的事情。但现在我们总算能看得见终点了,耶!

友情提示:这篇文章讲述的是一个漫长的旅程。非常漫长。你可能已经注意到你的滚动条现在非常小。我们遇到的问题并不是只在 Stack Exchange/Overflow 才有,但这些问题的组合还挺罕见。我在文章中会讲到我们的一些尝试、折腾、错误、成功,也会包括一些开源项目——希望这些细节对你们有所帮助。由于它们的关系错综复杂,我难以用时间顺序来组织这篇文章,所以我会将文章拆解成架构、应用层、错误等几个主题。

more ...