零信任介绍与相关资料推荐

2022年10月23日作者 qishiya

一般公司都会存在两个网络，一个是公司的内网，一个是外网，在办公室可以直接连接内网，比如内网的 OA 或者 MIS 系统之类的，这些系统是只能员工访问的，办公室外的人是无法访问的，但是遇到一个问题，比如员工去外面出差，或者在家办公，这个时候要连接内网的 OA 或者 MIS 之类的怎么办呢？传统的方法是通过 VPN，相信没几个人想用 VPN，VPN 会遇到稳定性等各种问题，所以有一些公司开始搞零信任方案。

什么是零信任

VPN 解决方案是基于网络的信任，比如你来到了公司接入网络，我就相信你是内部员工，你通过 VPN 验证后登录，也对你完全信任，零信任的方案正好相反，我对你的每一个行为都是零信任，也就是完全不信任，你的每一个行为我都要验证。

零信任是完全不信任网络，而是基于设备、用户、动态访问控制和行为感知策略。零信任需要一个强大的身份服务来确保每个用户的访问，一旦身份验证通过，并能证明自己设备的完整性，则赋予适当权限访问资源。所以这里有四个元素：验证用户、验证设备、权限控制、自学习和自适应。

最主要的特征是不在基于网络的信任，而是基于设备行为的验证。

零信任资料汇总

Google BeyondCorp 相关论文

最早是 Google 开始实践零信任方案，他写了 5 篇论文，要想了解 Google 的零信任方案是怎么设计并实施的，这 5 篇论文一定要读。

BeyondCorp: A New Approach to Enterprise Security – Google Research

BeyondCorp: Design to Deployment at Google – Google Research

BeyondCorp: The Access Proxy – Google Research

Migrating to BeyondCorp: Maintaining Productivity While Improving Security – Google Research

BeyondCorp: The User Experience (google.com)

Forrester Build Security Into Your Network’s DNA: The Zero Trust Network Architecture

为什么写博客

2022年1月4日2022年1月3日作者 qishiya

为什么写博客

流量不是我写博客的原因，我认为我的博客是记录我自己认知迭代的一个过程，哪一天不迭代了，可能也就离开这个世界了，我关注过一个博客，他写了 10 多年，后来不更新了，不久听说博主离开这个世界了，如果把博客提交给搜索引擎，或许可以帮到一些人，那就有双重收获了，一是记录了自己的迭代，二是也许能帮助一些人，看到很多留言，大部分是向我表示感谢的，但是也有一部分是来抬杠的。

我博客的流量来源

我的个人博客 qishiya.com 流量主要来自于 google、bing、百度这三个搜索引擎，没想到我网站的主要访客是来自于 google、bing 这两个搜索引擎，百度反而是最少的，仔细一想，也正常，因为我的网站主要是写一些经营 depop，aliexpress，怎么样买流量，怎么样提高效率的文章，而这些用户，基本上都是具备全球化视野的人，所以他们能使用 google 或者 bing 这样的搜索引擎。

用IFTTT把Twitter保存到Google spreadsheets

2021年12月16日2021年12月15日作者 qishiya

算了一下，平均每天有一个小时在 twitter 上看信息，twitter 是我获取信息的一个重要渠道，想把在 twitter 上的时间压缩到 5 到 10 分钟，但是 twitter 又不能自定义信息展示的优先级，要么 twitter 根据自己的算法推荐，要么切换到时间轴，根据时间来看，比如我关注 naval， paulgraham 等人，我想我每天看一下这几个人的信息就差不多了，可是在 twitter 你就必须点到他们的主页才能看到，所以比较低效，我找了一个工具，叫做 IFTTT，这个平台的方便指出是你可以指定一个数据源，指定一个目的的，比如我指定 twitter 的数据源，数据目的地指定为 google 的 spreadsheets，比如我可以设置一条规则，当 naval 发 twitter 的时候，IFTTT 就把这条信息放到 google spreadsheets 上，我每天固定的时候去看一下这个 spreadsheets 就要以了。

怎么样写好英文文档

2021年11月6日作者 qishiya

我以前发现只要学好英文基本上就可以和全世界大部分人交流，后来发现是错误的，碰到几个法国人，她就不喜欢和你说英文，我给她们发英文邮件，她们就用法语来回复，这样的事情在意大利人身上也存在，在德国人身上也出现过，在阿拉伯人、俄罗斯人身上都碰到过，后来我才知道，很多电商平台是提供多语言版本的，比如 aliexpress 本地化就做的很好，同样一个商品，你在俄罗斯看到的可能是俄语，在意大利，可能看到的是意大利语，全球有这么多种语言，一个人再怎么牛，也不可能懂所有的语言，我查了一下 google 上支持的语言，多达 100 多种，完全靠人工去翻译，肯定不现实。

人类擅长制作和使用工具，如下这些工具是我经常使用的，基本上每天都会使用，已经推荐给了身边很多朋友，他们用过后非常满意。

为什么程序员害怕转管理岗

2021年10月12日作者 qishiya

最近在读《Software Engineering at Google》时，讲到了一些技术人员害怕转管理岗，我也有过相同的经历，记录一下 google 是怎么样处理这种情况的。

Google 会有三种角色，分别是工程经理(Manager)、技术主管(TL)、技术经理（TLM），如果是特别小的团队，这两个角色由一个人来担任（TLM），否则这两个角色有不同的人来担任。

Google 是怎么样下线过期系统的

2021年10月9日作者 qishiya

在公司经常碰到的情况是新系统开始好了，但是旧系统一直还被人依赖，让使用者迁移，一般都不会怎么顺利，记得我当年在某一个大厂时，新旧两套系统同时跑了快一年，旧系统最大的问题是需要维护，同时维护两套系统的成本很高。
记录一下 Google 是怎么处理这个问题的，有一些主张还是比较有意思。

Google 是怎么样打造团队合作的

2021年10月8日作者 qishiya

没有神

许多人都有寻找和崇拜偶像的本能，对于软件工程师来说，他们可能是 Linus Torvalds、Guido Van Rossum、Bill Gates，他们都是以英勇壮举改变世界的英雄，Linus 自己写了 Linux，对吧？

实际上，Linus 所做的只是编写了一个概念验证类 Unix 内核，并将其发布在电子邮件列表中。这是不小的成就，绝对是了不起的成就，但这只是冰山一角， Linux 比最初的内核大数百倍，是由数千名聪明人开发的， Linus 真正的成就是领导这些人并协调他们的工作； Linux 不是他最初的想法，而是社区集体劳动的光辉结果。（Unix 本身并不完全是由 Ken Thompson 和 Dennis Ritchie 编写的，而是由贝尔实验室的一群聪明人编写的。）
同样，Guido Van Rossum 是否亲自编写了所有 Python？当然，他写了第一个版本。但是其他数百人负责为后续版本做出贡献，包括想法、功能和错误修复。史蒂夫·乔布斯 (Steve Jobs) 领导了一个构建 Macintosh 的整个团队，尽管比尔·盖茨 (Bill Gates) 以为早期家用计算机编写 BASIC 解释器而闻名，但他更大的成就是围绕 MS-DOS 建立了一家成功的公司。然而，他们都成为了所在社区集体成就的领导者和象征。天才神话是我们作为人类需要将团队的成功归因于一个人/领导者的趋势。

Google 是怎么样写文档的

2021年9月29日作者 qishiya

总结

时间越久，规模越大，文档越显得重要。
文档的变更要加入到开发人员的工作流程。
写文档的目标应该单一，不应该一个文档满足不同的目标。
明确读者是谁，而不是为了写给自己看。

google 是怎么样对待文档的

在谷歌，我们将文档视为代码并纳入开发的工作流，使工程师更容易编写和维护简单的文档。

可以看出 google 对文档的重视程度，文档和代码同级别，并且文档也和代码一样，有工作流。

google 是怎么样衡量工程生产力的

2021年9月28日作者 qishiya

有的流程或者工具会促进工程生产力（工程师的生产效率），有的就不会，比如代码规范，代码的可读性规范，会促进工程生产力，那么怎么样去衡量是真的促进了工程生产力，还是假的呢？用了如下的方法。

来自于《Software Engineering at Google》这本书，好奇 google 是怎么样去评价工程师的生产效率的，发现主要是用了一个叫做 Goals/Signals/Metrics (GSM)的框架，

Goals(目标)
Signals(信号量)
Metrics(指标)

Google 2021 DevOps 报告发布

2021年9月27日作者 qishiya

Google 发布了 2021 Accelerate State of DevOps Report报告，粗略总结一下。

四个指标

deployment frequency（部署频率）
lead time for changes（变更准备时间）
mean-time-to-restore（平均恢复时间）
change fail rate（变更失败率）

四种级别的团队或者组织

Elite (精英)
High（高）
Medium（中）
Low（低）

从这个报告可以发现，我们看到精英团队继续加快他们的软件交付速度，将他们的变更准备时间从不到一天降到不到一个小时。不仅如此，精英企业的部署频率是低绩效企业的973倍，部署的准备时间是低绩效企业的6570倍，变更失败率是低绩效企业的3倍，当失败发生时，恢复时间是低绩效企业的6570倍，与低绩效者相比，精英绩效者能够不断地根据经验证明组织在DevOps方面的成功。