引子​

“所有模型都是错的，但有些很有用。”--George Box

数据分析对于很多人来说既熟悉又陌生。数据小白们觉得各种五颜六色的图表仪表盘看起来很酷炫，运营管理者们认为统计数字和时间趋势图可以帮助他们做业务决策，程序员们认为数据分析无非就是从数据库中将目标字段的数据按照一定要求捞取出来。这些看法都没错，但真正有用的数据分析，除了将数字呈现出来，还将发现的数据洞见与业务充分结合起来，实际为业务创造价值才有意义。了解一些基础统计学知识，很可能会对发现洞见有帮助。

平均值并不可靠​

我们经常可以看到很多数据报表中会呈现出按照每天、每周、每月的平均数，例如当月每日平均销售额、去年每月平均访问次数，等等。平均值统计对某些特定的情况会有所帮助，例如每天起床的时间、瞄中射击靶心的偏移量。但更多的时候，你很可能会对平均值产生怀疑，因为平均数很多时候会上下波动，而且波动幅度还会很大。这里的根本原因来自于真实世界中的非线性分布（Non-Linear Distribution）。对于网站的响应时间、网页访问次数、股票走势的分布，都属于非线性分布。在这些非线性分布中，平均值就失效了，因为有大量的异常值（Outlier）让平均值产生了严重偏离（Skewed）。就像下图一样，对于自然分布（Normal Distribution）或高斯分布（Gaussian Distribution）来说，它是线性分布（Linear Distribution）的，因此平均值在其分布的正中间的峰值位置；但对于 Gamma 分布来说，因为它是一个非线性分布，其平均值严重偏离其峰值，而且当离群值越来越多，其平均值会进一步偏离其中心位置。

因此对于这些非线性分布来说，平均值就不是一个合理的判断指标，而咱们可以采用中位数（Medium）来表示其大致的中心位置。咱们有很多种处理这种非线形分布的工具，其中一种就是箱线图（Box Plot）。如下图，两个分布被抽象为了一个箱和几条线，其中箱中心线就是中位数，而边缘是四分之一和四分之三分位线。这样不需要做过多复杂的分析就可以在一张图上一目了然的看出大致的分布情况。

引子​

“生命是靠负熵来维持的。”--《何为生命》埃尔温·薛定谔

在如今的互联网时代，数据是企业重要的资产。我们无时无刻不在产生数据：每一次打开手机应用，每一次网购下单，甚至每一次驾车穿过红绿灯，都会产生数据。数据无处不在。在企业中也更是如此。如此之多的原始数据，加上日渐成熟的数据分析技术，让企业家们大为兴奋，因为这就是企业堆积如山的金矿啊。然而，事情并没有想象中的这么简单，要从这些杂乱无章的酷似垃圾堆的所谓 “金矿” 中提取有价值的宝贝，并不容易。笔者之前的文章《浅谈数据：数据领域需要掌握些什么？》也稍微提到了数据治理（Data Governance）这个概念。本篇文章将从企业数据管理的角度，介绍数据治理是如何在混乱的企业数据中创造价值的。

数据孤岛问题​

中大型企业（一般超过 100 人，且有多个职能部门）在快速发展业务的同时，也会遭遇管理混乱的问题。销售部门有着自己的销售统计数据，通常是庞大而分散的 Excel 或者简单的在线表单；IT 部门自己建立且管理一套资产和库存系统；HR 部门又维护着一整个人员统计名单。而这样的情况会导致不少头疼的事情：大老板抱怨每周才能收到整个公司运营的管理报表；经理们看着报表中忽上忽下的数据，怀疑着真实性；基层员工加班加点整理好老板要的数据，却被质疑数据有问题。熟悉么？这些都是企业中经常发生的问题，其直接原因就是所谓的数据孤岛（Isolated Data Island）问题。

引子​

如今很多云原生系统、分布式系统，例如 Kubernetes，都是用 Go 语言写的，这是因为 Go 语言天然支持异步编程，而且静态语言能保证应用系统的稳定性。笔者的开源项目 Crawlab 作为爬虫管理平台，也应用到了分布式系统。本篇文章将介绍如何用 Go 语言编写一个简单的分布式系统。

思路​

在开始写代码之前，我们先思考一下需要实现些什么。

• 主节点（Master Node）：中控系统，相当于军队中的指挥官，派发任务命令
• 工作节点（Worker Node）：执行者，相当于军队中的士兵，执行任务

除了上面的概念以外，我们需要实现一些简单功能。

引子​

前不久在关于 CI/CD 文章《实战 CI/CD：微软加持的 GitHub Actions，怎么用才香？》中简单介绍了一下 GitHub 的官方 CI/CD 工作流服务 GitHub Actions，用一个实际的 Python 项目例子做了演示。不过，这部分内容相对较初级，而对于一些大型项目来说，我们可能需要更复杂的工作流。而这篇文章的主要目的是帮助开发者们熟悉软件开发中的工程化部分。

本篇文章以实际的大型项目为例，介绍一下笔者的开源项目 Crawlab 在 GitHub Actions 中的 CI/CD 应用。对 Crawlab 不熟悉的读者，可以参考一下官网或官方文档，简单来说，Crawlab 就是能帮助提高数据采集效率的爬虫管理平台。

整体 CI/CD 架构​

Crawlab 新版本 v0.6 将不少通用的模块进行了拆分，因此整个项目由多个子项目依赖组成，例如主项目 crawlab 依赖于前端 crawlab-ui 和后端 crawlab-core。这样切分成多个子项目之后，各个模块耦合性降低，可维护性增加。

以下是 Crawlab 的整体 CI/CD 架构示意图。

引子​

“话说天下大势，分久必合，合久必分。” --《三国演义》罗贯中

很少有人能质疑算法（Algorithm）在现代 IT 行业中的重要地位。正是有了巧妙设计的算法，计算机才能以最小的资源和最大的效率来运行各种各样的软件程序。因此，算法非常重要，以至于不少 IT 企业在招聘工程师时对算法要求非常高。回忆一下你参加过的技术面试被要求手写快速排序的算法题吧。不少人会认为算法是高屋建瓴的东西，然而笔者却认为算法以及数据结构产生的效率增益是自然形成的，这个可以从大自然中找到答案。

从雪花开始​

我们都知道，一片雪花很漂亮，除了它明亮的外表以外，令人惊叹的还有其造型：整体像雕琢过的六边形，每个角放大来看又是新的类似雪花的子六边形。这种自相似（Self Similarity）不断递归（Recursion）的结构有个专业术语，分形（Fractal）。分形在大自然中随处可见，例如树的根系和枝叶、肺部毛细血管、天然形成的海岸线，数不胜数。甚至连一块摔碎的玻璃，也能找到分形的影子。

引子​

GitHub Actions 是 GitHub 官方推出的 CI/CD 工作流（Workflow）服务，旨在减轻开源贡献者们运维负担，让云原生 DevOps 赋能开源社区。如果您不知道什么是 CI/CD、DevOps，请参考笔者之前在夜幕团队公众号写的文章《用开源软件轻松打造企业级DevOps工作流》。笔者的开源项目，例如 Crawlab、ArtiPub，都集成了 GitHub Actions。作为开发贡献者，我认为 GitHub Actions 不仅好用，而且是真香免费（这是最主要的）。希望很多不了解如何将 GitHub Actions 运用在自己的开源项目的开发者，可以从本文中得到灵感。

从官方文档开始​

对于 GitHub Actions 不熟悉的朋友，我强烈推荐你先阅读 GitHub Actions 官方文档，这里有视频介绍、快速开始、例子、概念、原理等等。如果把文档研究透了，再结合自己平时运用 CI/CD 的经验，应该可以很轻松的在 GitHub 上做 DevOps。本文所用到的相关代码，都可以在官方文档上找到对应的参考指南。

思路​

先理清一下我们想要实现什么：用 GitHub Actions 来运行仓库中的爬虫获取每日 GitHub Trending。

引子​

"开发安全可靠的应用程序的最好方式，就是不写代码。"--Kelsey Hightower

很多开发者应该或多或少听过单元测试（Unit Tests），甚至编写过，也或许对其有所了解。不过，在如今瞬息万变的环境下，单元测试似乎正在成为鸡肋。程序员们都知道它的好处，但是对其显得比较冷淡。“进度这么赶，还有什么时间写单元测试呢？”这样的话是不是听着很熟悉？

单元测试是什么？​

所谓单元测试，简而言之就是程序员编写测试代码来验证自己写的功能代码是否能按照要求运行。如果测试代码不能通过，就说明自己写的功能代码是有问题的。

这种自己测自己的方式似乎有些可笑，相当于考试时看着答案做题。然而在测试领域，这样的方式有个专业术语叫白盒测试。而白盒测试的对立术语叫黑盒测试，也就是用其他方式来验证。单元测试属于白盒测试，而更高级的测试例如集成测试（Integration Tests）、端到端测试（End to End Tests）、UI 测试（UI Tests），都属于黑盒测试。单元测试仅仅是测试代码本身。

单元测试有什么用？​

单元测试在敏捷开发（Agile Development）中是非常有用的工具。甚至有些敏捷框架，例如极限编程（XP），就要求每一个功能必须被单元测试覆盖。在之前的文章《浅谈敏捷：你的团队在正确实践敏捷吗？》就提到过单元测试的重要性。

引子​

“据不完全统计，数据从业者的白头发占比高于同年龄段的平均值”---某数据从业者

数据（Data），这个对不少人来说熟悉而神秘的词语，似乎已成为各行各业都在追捧的图腾。管理者们喜欢看到五颜六色的炫酷报表，数据分析师们热衷于构建专业复杂的概率模型，业务员们将数据仪表盘作为自己能否完成业绩目标的指南针。最近十几年，数据行业飞速发展，诞生了大量让人望而生畏的专业名词，例如大数据（Big Data）、数据科学（Data Science）、数据湖（Data Lake）、数据网络（Data Mesh）、数据治理（Data Governance）；当然，那些“传统”的专业词汇也让人头疼，例如数据仓库（Data Warehouse）、商业智能（Business Intelligence）、数据集市（Data Mart）、数据挖掘（Data Mining）；而更可怕的事实，很多人可能还不清楚这些名词跟最近大火大热的人工智能（Artificial Intelligence）、机器学习（Machine Learning）、深度学习（Deep Learning）有什么联系。这些火热的名词背后，都是数据领域野蛮发展的必然结果。

专业医生还是算命先生？​

多年前，互联网行业蓬勃发展，而数据行业的泡沫也日益增长。数据作为互联网应用的副产物，容量巨大而又丰富，很多互联网企业一门心思想要从中获取进一步增长，这是因为很多企业家将其视为金矿，进而也让数据挖掘工程师们成为了炙手可热的明星职业。之后，更火的职业应运而生，数据科学家（Data Scientist）被称为 21 世纪最性感的职业。

数据科学家职业的火爆是由于它要求多方面的经验能力：

• 编程能力：至少要用 Python 或 R 进行数据清洗、分析、建模
• 数理统计：熟练掌握概率论、微积分、离散数学等专业学科知识
• 业务知识：对相关业务领域的市场、流程、宏观趋势有深刻理解
• 沟通能力：能将分析结果以普通人类能够理解的方式表达出来

引子​

任务调度（Task Scheduling）是很多软件系统中的重要组成部分，字面上的意思是按照一定要求分配运行一些通常时间较长的脚本或程序。在爬虫管理平台 Crawlab 中，任务调度是其中的核心模块，相信不少朋友会好奇如何编写一个任务调度系统。本篇文章会教读者用 Go 语言编写一个非常简单的任务调度系统。

思路​

我们首先理清一下思路，开发最小化任务调度器需要什么。

• 交互界面（API）
• 定时任务（Cron）
• 任务执行（Execute Tasks）

整个流程如下：

我们通过 API 创建定时任务，执行器根据定时任务标准定期执行脚本。

引子​

“今天加一下班把这个需求做了吧，老板催得很急。”--某时某厂某项目经理

敏捷，这个曾经作为灵活速度的代名词，在过去 20 年里逐渐发展成为 IT 界中被程序员们时常挂在嘴边的看似深奥的专业术语。敏捷开发（Agile Development）作为很多开发团队的项目管理框架首选，因为其简单、灵活，更重要的是它字面上暗示着 “快”。想一想无数码农为了赶进度而无偿加班吧。

敏捷 = 快速交付？​

当你的开发团队遭遇项目延期、产品质量降低、士气低下以及客户关系恶化时，你的朋友或许会推荐你使用敏捷开发：“嘿，兄弟。我听说最近敏捷挺火的，你可以试一下。” 但是，当你在团队中推行敏捷一段时间后，你很可能会发现它并不好使：产品发布后依旧大量的bug、无穷无尽的加班、源源不断的最高优先级需求。在与老板的日常会议中，老板问你：“听说你们正在用敏捷来提升交付效率，很棒！所以我下周能看到之前给你提的重要功能吗？”

“敏捷就是快速交付”，这是很多敏捷实践者中最大的误区。其实，敏捷并不一定意味着快；相反，它还会引入更多额外工作，从而可能导致更慢的交付功能。对，你没看错。严格意义来说，敏捷会降低交付速度。例如，极限编程（XP，敏捷框架之一）要求为每一个功能编写单元测试，这会引入 1-2 倍的额外代码。