查看原文

ChatOps 在处理 Incident Management 的时候，主要关注的是沟通，确保各方的响应确切地在推进事故的应急处理。Shopify 采用的 Incident Response Process 叫做 Incident Command System (ICS)。在这个模型中，Commander (IMOC) 领导整个事故应急处理，Public Information Officer 对外沟通，Operations 对内处理。

有个概念不能混淆：Incident Response 不是修复生产环境的 bug。这个流程基本上是这样的：

• 检测到除了问题。
• IMOC 评估确认问题，发起一次 incident。
• IMOC 协调沟通，确认修复和多久可以搞定。
• 故障解除，IMOC 确认，停止 incident，写服务挂掉的报告。
• RCA 接入 …

查看原文

以下是几个写代码的建议：

• 看一个陌生的大项目代码，先找到几个领域关键词，然后过一遍代码库，看看这几个词之间是怎么相互产生关系的。
• 留出足够的时间写测试。
• 评估任务的时候，就把接口和实现都想清楚。把事情搞的透明，对团队也是一件好事。
• 小步快跑，一有代码变更就推出去PR，让人 review。
• 通过工作时间写的代码磨练自己的技能，而不是靠 side projects。

查看原文

本文是 Dropbox 内部关于安全实践的一些简介。

• 首先，他们关注员工的安全意识。它们做年度安全培训。由于抓过现行，员工家属曾经攻击或造成内部问题，所以他们的解决方案是希望培养文化，"安全生产"。
• 其次定期测试和提升安全。这些测试包括：渗透测试，产品安全评估，邀请专业 red team 帮忙测试等等。内部的 Offensive Security team 在每天做对抗测试。此外，公司有对外的悬赏项目：Bug Bounty Program。
• 还有造工具：例如 Security Bot，检测暴力破解密码的行为，甚至如果商业工具不够用，就自己造 （Mac OS host monitoring）。
• 帮助用户提高安全意识，提供多步验证，支持 U2F keys。

查看原文

RBAC = Role Based Access Control, 在系统中一般是处理 Organizing Permissions，规定谁能干什么。RBAC 系统的核心概念有：Role, Permission, Operation。例如一个用户有很多种角色，一个角色有很多种权限，一种权限能执行多种操作。

• 在代码中，不建议这么写代码：if user.role in ['admin', 'xyz']:，而应该写作：if user.can(Permission.EDIT_REPORT, report)。如果直接将用户和角色挂钩，那代码库里面就会时不时有代码变更。建议的处理方式是：将 role x permission 在代码中解耦，数据库中存这份数据。
• 权限一般 Positve，不要 Negative：统一风格，权限是 用户能做什么, 而不是 …

查看原文

Python 虚拟环境工具：Hatch, VirtualEnvManager, autoenv, fades, inve, pew, pipenv, pyenv-virtualenv, pyenv-virtualenvwrapper, pyenv, pyvenv, rvirtualenv, tox, v, venv, vex, virtual-python, virtualenv-burrito, virtualenv-mv, virtualenv, virtualenvwrapper-win, virtualenvwrapper, workingenv。

但是究其本源，用的技术都是 virtualenv environment。它是一个自包含的目录结构，里面有 特定版本的 Python 解释器，外加一些程序库。PEP 405 描述了什么是 Python Virtual Environments。基本上该目录要满足两个条件：

• 有个文件 pyvenv.cfg，文件内容有 home = /usr/bin …

查看原文

在 Nagios 对 Service 或者 Host 做可用性检测的时候，可能会出现 Flapping 现象。Flapping 是指服务或节点状态变更太频繁，一会儿好，一会儿不好。它可能是因为服务负载太高，也有可能是网络问题。Nagios 的检测算法是：

• 存最近 21 次的检测结果
• 检测状态变更了 N 次
• 算 N / 21 = m %
• 把 m 跟设定的最高和最低的两个阈值比对，比 high 阈值高的话就是开始 flapping，比 low 阈值低的话 flapping 就认为停止了。

例如，21 次变更，丢了一次，变更了 7 次，那结果就是 7 …

查看原文

atime 是 last access time。noatime 是 Linux Mount 文件系统的选项，指的是当设置后，文件的 atime 便不再更新。正常情况下，每次文件读操作，都会给文件的 inode 写入 atime 数据。关闭这个选项可以提高性能。

具体做法是在 /etc/fstab 中设定 mount 的节点，加上一个 noatime。不需要重启操作系统，直接 mount -o remount / 加载新的设定。

查看原文

MySQLStreamer 是 Yelp 的数据流水线组件，用于将数据从 MySQL 集群流式传输到 Kafka 数据流水线。为了实现从 100 qps 到 n kqps 的流量变迁，他们用了一些手段做性能优化：改变部署模型，运行在 PyPy 上，优化日志。具体来说，步骤如下：

• 定义核心的性能指标，主要是吞吐和延迟。
• 程序发出这些指标数据到时间序列图表程序去。
• 代码里加上 Profiler。
• 部署一个跟生产环境一样的 Canary 环境，可以测出性能问题。
• 理解程序的瓶颈，哪里最费时。
• 跟生成的 Profile 火焰图做对比，看看是否符合预期，如果不是的话就剖析，然后 fix。
• 持续迭代这个过程。

查看原文

发布于 2014 年的响应式宣言描述了响应式系统的必须特征：responsiveness, resiliency, elasticity, and being message driven, 其中岁重要的特征是最后一项。这意味着整个系统需要设计成异步的，面向消息的。

例如设计实时的广告追踪系统，流量忽大忽小，系统要面对突如其来的流量高峰。很多数据又要尽可能放在内存已保证快速响应。程序中的非实时的功能，让另外的程序慢慢消费它们。这么一看，系统主要可以拆分为数据收集，核心数据存储，实时接口，非实时消费等部分。

实例程序基于 Java8 框架 Vert.x, 运行在 JVM 上，IO 库使用 Netty。基本的并发模型是是 actor-like，写起代码来基本上就是实现 Verticle 接口，和一个 single event bus 通信，收发消息。Vert.x 使用 …

查看原文

MySQL 运行在 Linux 上，在调优性能时要关注的几块地方：

• IOscheduler,
• 内核版本
• IRQbalance
• 文件系统，开 noatime, nobarrier 选项
• 调 ulimit
• 调 swappiness 内核参数
• 上 Jemalloc，如果必要的话
• 配置 iptables, pam