SONiC是微软Azure推出的一个开源的网络操作系统，它通过微服务的思想，将网络操作系统中各个服务容器化，并利用中心Redis数据库进行协作，使得每个服务都可以独立的开发、测试、部署、升级，大大的提高了网络操作系统的可靠性、可扩展性、可维护性。现在SONiC支持的交换机厂商也非常的多，包括：Arista、Broadcom、Cisco、Dell、Edgecore、Mellanox等等。然而，一台DCN交换机的价格是非常昂贵的。如果你和我一样，想试一试SONiC，但是又不想花钱买一台SONiC的硬件设备，那么这篇文章就是为你准备的。本文会大概总结一下如何通过GNS3在本地搭建一个虚拟的SONiC的Lab，让你可以很快的在本地体验一把SONiC的基本功能。
在本地运行SONiC的方法很好几种，比如docker + vswitch，p4软交换机等等，对于初次使用而言，用GNS3可能是最方便快捷的了，所以本文就以GNS3为例，介绍一下如何在本地搭建一个SONiC的Lab。那么，我们就开始吧！
在上一篇，我们总结了和中断相关的概念和x86平台下最基础的，基于PIC的，中断处理流程。虽然看起来PIC可以很好的解决中断的问题，而且凭借主从扩展，能力也不错（默认支持15个设备，最多64个设备），但是随着系统的发展，多处理器系统开始出现，PIC的结构就不够用了，所以，APIC（Advanced PIC）就出现了。在这一篇中，我们就来看看吧！
我们知道PIC和CPU直接相连，所以PIC其实是一个全局的中断控制器，也就是说，它只能支持一个CPU。而随着系统的发展，多核处理器开始出现，有很多问题PIC就无能为力了，比如：
于是为了解决这些问题，APIC就被发明了出来。
这段时间想把Linux的网络栈给理顺一下，然后发现在读书的时候，很多书对于中断的产生都是很快的带过了，解释的并不是非常的清楚。虽然这个原因很好理解 —— 这些书的重点在于内核如何处理，但是我总觉得这样的话，我的知识的拼图就少了很重要的一块，所以就单独看了看（硬件）中断这一部分。看完之后发现其实内容也挺多的，所以在这里小小的总结一下，正因如此，这篇博客会更加注重硬件的层面，至于软件上如何进行处理，大家可以参照对应的内核书籍，这里就不多说了。
另外因为内容太多，所以这篇文章主要会借用x86/x64的架构来作为例子，arm的架构我们可以在后面的文章中再来讨论。
好了，闲话少说，我们这就开始！
所谓中断，顾名思义，就是一种可以打断处理器当前运行的程序，转而去运行其他的程序的方式。当某些特定事件（event）被触发，如外部设备完成特定操作，或者执行了未知的指令，或者访问了无法访问的内存，处理器就会触发一个中断请求（IRQ, Interrupt Request），来对其进行处理。通过这种方式，我们可以快速的对这些事件进行响应。
中断理论上分为三类：外部中断（External Interrupt），软件中断（Software Interrupt）和内部中断（Internal Interrupt）。不同的平台的分类经常有些许不同，但是大体都差不多，比如，intel就把它分类为：外部中断，可忽略的硬件中断，软件中断和异常。所以这里我们就不过多的对它们的叫法进行展开了，而是来依次看一看其内部的细节。
我们终于来到了这个系列的最后一篇，在上一篇中，我们讨论了如何写出好的测试，如何利用数据驱动测试来降低测试的维护成本，提高程序和测试的可观察性，并且提高错误调试的速度。希望到了现在，你会开始觉得数据驱动测试相当方便，并跃跃欲试的想在自己的项目里面进行实践。
不过，如果我们仅仅到此为止，那就真的太浪费了。我们还只刚刚解锁了它的一半威力而已！我们这一篇就来讨论以下它的进阶版本，我称其为面向数据的测试，并且利用它做到线下测试即线上测试，从而实现测试的大统一！
首先，我们先来快速回顾一下数据驱动测试吧！
数据驱动测试，顾名思义，其特点就是将被测试程序的输入通过数据的方式进行存储，并在测试时依次循环执行，最后将被测试程序的输出与预先设置好的期望结果进行对比，从而达到测试的目的，流程大致如下：
我也不知道是为什么，就是突然很想看这本书，但是文言文真的好难啃啊，于是这几周就一直在读这一本书……
《孙子兵法》这本书很有意思，读完之后发现，其中最著名的几句话，也是对其误读最深的几句话，比如“兵者，诡道也”，比如“置之死地而后生”。本来是打算把这本书当作一本故事书读着玩的，结果哪里知道，这本书讲的全然不是什么诡道，特别的平实，满满的正能量，他教我们怎样做事，怎么管理企业和团队，怎么样评估风险控制预算，等等等等。真的没想到几千年前讲的东西，哪怕是到了现在都非常的实用。也许不管时代怎么变，科技怎么发展，人，终究还是人吧……
另外一个有意思的地方就是，其实《孙子兵法》有很多内容甚至核心思想也都不是其原创，而是更早的人发明了之后流传下来的。这个人便是黄帝身边的宰相，叫做风后。没错，就是《一人之下》里风后奇门的风后。除了因为风后是最早发明这些兵法的人，还因为风后留下来到现在著作《八阵图》和《握奇经》里面详细描述了如何运用八卦进行阵法布置，所以就有了《一人之下》里面的风后奇门的演绎了。
好了，让我们说回正题——《孙子兵法》吧。
在现在这个遍地996福报的年代，人们的生活压力越来越大，沟通的便捷让工作几乎侵占了生活的各个角落，老板们周末在微信群里的胡言乱语，同事们随意发送的“有空吗”的垃圾信息，在家办公导致工作更加没有边界，这些都让我们的生活越来越疯狂。然后，2020年下半年，重来3出来了，给我们描绘了一个安居乐业的美丽新世界！**这本书的目标只有一个，那就是帮助我们打造一个冷静的公司，拒绝加班，拒绝没必要的压力。**虽然在这个军备竞赛的年代不知道什么时候才能真正做到，但是我们每个人都可以开始慢慢从点滴做起，毕竟每周40个小时的工作制是前人们拿性命换回来的，别就这样随手又还给了资本家。
虽然没有加班的世界确实很美好，但是这并不意味着大家可以任意摸鱼，也不意味着公司无所求的无限付出。为了实现这个美丽新世界，我们需要先来了解一下它的大前提，这些虽然在重来3里被一笔带过，但是作者其实是用了《重来1》和《重来2》两本书来解释的。
首先，**最重要的就是人，真正优秀的人！**重来2花了一整本书来介绍远程办公的可行性，其原理就是创建一个正向的反馈，因为远程办公带来的跨时空的便利性，所以公司可以不受约束的寻找最优秀的人才，而这些优秀的人也让远程办公变得更加可行。一旦正向反馈被创建起来，公司就能走向正轨，可是如果员工利用便利天天摸鱼，那很快公司就会完蛋。那我们要寻找什么样的员工呢？重来2中也给出了答案：
这本书很有意思，成书于2014年，豆瓣上现在只有7.2分。很多热评都是在五六年前留的，嘲笑这本书上不切实际的评论铺天盖地。结果呢，去年新冠爆发，科技公司的员工基本全都开始了在家办公，硬生生的把大家狠狠的推了一把！一开始我没做好准备，各种不适应，可是谁也没想到最后的结果却是，效率比在办公室来的更高了，周围的人以前看不出来的各种才华也开始显现了，画画的，跳舞的，甚至出唱片的，百花齐放，而真的有机会见面的时候就更加开心了，一种老友相见的感觉，唠不完的磕～
这个时候再回头看这本书，觉得作者真是先知，每一条都戳在我的痛点上，看完感觉真的学到了不少，于是继续做个笔记，也给大家强烈推荐这本书，别因为豆瓣低分就错过了～
这本书的作者之一是Ruby on Rails的创始人，David Heinemeier Hansson (DHH)，就和书里面说的一样，这本书应该是DHH他们创业之后的副产品 —— 一本讲如何创业的书。虽然如此，但是其不仅仅只对创业有用，对平时的工作也有很帮助。
书里面讨论了创业时心态和方法的方方面面，但我觉得这本书的核心观点归根结底就是作者之一Jason Fried的座右铭：“It’s simple, until you make it complicated.”
如果你打算创业，那么首先你得为自己卸负。灵感稍纵即逝，有了好的点子，就应该立刻放手去实现，不要为自己找借口。团队小并不是一件坏事，因为它足够灵活，非常适合前期探索和试错。一开始没有投资也不是什么坏事，拉来的投资也就意味着丧失了话语权。另外，行动前，向成功学习成功的经验，而不是失败；
In the last post, we discussed the reasons for writing tests, principles and how to write code that is easy to test. In this post, we’ll discuss more on how to write good tests.
First, let me repeat the important thing: Test is a not a silver bullet. Adding a few tests won’t help us improve the code quality that much. If you haven’t read the part 1 yet, it is highly recommended to read it first.
We are finally here! Let’s talk about writing tests! Making code easy to test is only the first step, and to write good tests we will need some more skills.
We know that there are various types of tests. And here are some examples:
“Please write a UT for this change.” is one of the most frequent comments I leave in the code review. And I am seeing people tend to write minimum tests just for having something to pass the review.
Well, I kind of understand writing tests is annoying sometimes, but tests are extremely helpful and there are things could help us writing them too. So let’s talk about test!
“Hey! It compiles! Ship it!”
When talking about writing tests, many people find it annoying for simliar reasons:
All these questions and complaints are basically because we don’t understand the real intention of testing, and finally fall into the misunderstanding of writing test for the sake of writing tests. And when we are forced to do something, we are never going to feel it will benefit us, even if it really does.