ARTS的初衷
- Algorithm：主要是为了编程训练和学习。每周至少做一个 leetcode 的算法题（先从Easy开始，然后再Medium，最后才Hard）。进行编程训练，如果不训练你看再多的算法书，你依然不会做算法题，看完书后，你需要训练。关于做Leetcode的的优势，你可以看一下我在coolshell上的文章 Leetcode 编程训练 - 酷 壳 - CoolShell。
- Review：主要是为了学习英文，如果你的英文不行，你基本上无缘技术高手。所以，需要你阅读并点评至少一篇英文技术文章，我个人最喜欢去的地方是http://Medium.com（需要梯子）以及各个公司的技术blog，如Netflix的。
- Tip：主要是为了总结和归纳你在是常工作中所遇到的知识点。学习至少一个技术技巧。你在工作中遇到的问题，踩过的坑，学习的点滴知识。
- Share：主要是为了建立你的影响力，能够输出价值观。分享一篇有观点和思考的技术文章。
作者：陈皓
链接：https://www.zhihu.com/question/301150832/answer/529809529
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
Algorithm
给定一个整数数组 nums 和一个目标值 target，请你在该数组中找出和为目标值的那 两个 整数，并返回他们的数组下标。
你可以假设每种输入只会对应一个答案。但是，你不能重复利用这个数组中同样的元素。
示例:
给定 nums = [2, 7, 11, 15], target = 9
因为 nums[0] + nums[1] = 2 + 7 = 9
所以返回 [0, 1]
来源：力扣（LeetCode）
链接：https://leetcode-cn.com/problems/two-sum
著作权归领扣网络所有。商业转载请联系官方授权，非商业转载请注明出处。
使用字典hash的方式，缩短查找目标元素的时间，有点取巧。
class Solution:
def twoSum(self, nums: List[int], target: int) -> List[int]:
nums_index = {}
for i in range(len(nums)):
nums_index[nums[i]] = i
for i in range(len(nums)):
num2 = target - nums[i]
j = nums_index.get(num2)
if j and i != j: #需要注意i和j不能相等，因为不能重复利用
return [i, j]Tip
1. 使用ldd确认库文件依赖路径是否有问题
ldd <file>可以看到库文件的链接情况，用来帮助排查依赖库缺失的问题。ldconfig可以用来重新生成动态链接库的缓存/etc/ld.so.cache，输出结果是有加载顺序的。
linux-vdso.so.1 => (0x00007fffbb763000)
libcudart.so.10.0 => /usr/local/cuda/lib64/libcudart.so.10.0 (0x00007fa9ef69a000)
libcublas.so.10.0 => /usr/local/cuda/lib64/libcublas.so.10.0 (0x00007fa9eb104000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa9eaee7000)2. 使用strace分析进程执行耗时，追踪程序问题
https://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/strace.html
Review && Share
https://landing.google.com/sre/
What is SRE? Hear from our SREs
视频中讲了很多谷歌的SRE对于SRE工作的理解，回答了一些网友的提问（很多也是我的疑问）。正式工作了16个月了，title是SRE，最近却觉得干的活是打杂，sigh~，我需要好好想想自己的处境，想想怎么改变现状，想想自己的成长，不能就真的一直“打杂”下去啊。
视频中关于SRE的事情，其实在《SRE Google运维解谜》这本书中都有提到，不过我做了归类整理和自己的日常工作进行对比。
What do SRE do?
自动化和消灭琐事（Toil）
- 自动化不是脚本化，如果整个流程中引入了人工确认，就会引入人工操作失误的风险，导致整个流程的执行效率变低；
- 不只是承担琐事，也要去消灭琐事，一个人能cover住的运维琐事是有限的，如果不通过自动化工具减少，会导致overload；
- 琐事（包括oncall）的比例不高于50%，如果一个服务频繁报警，导致SRE需要经常人肉运维；那么就需要重新审视整个服务的稳定性状况和SLO了，对于不稳定的服务需要投入人力去提示其稳定性；SLO如果设置太高导致频繁报警，就适当调整SLO；对于达不到SRE运维要求的服务，SRE可以选择退出该服务的运维支持（这需要SRE有足够多的话语权）
这些东西在我的日常工作中也有遇到，然而最近半年多有这么一直趋势，我就算是在非oncall时间，也会被各种琐事包围，有些是必要的（我称之为必要琐事，例如业务逻辑梳理、报警覆盖梳理，但是这部分工作也因为需求变化的问题，导致重复梳理），有些是可被自动化或者干脆就是人肉填系统流程的坑（这些是可以被自动化消灭的Toil，例如服务手动缩容降配、SSH相关问题、工单执行失败处理、CMDB数据修正、其他值班人未及时相应的需求等等）。“必要琐事”是我是可以接收的，在熟悉之后，业务相关的梳理成本是可控的。“Toil”琐事是我想要消灭的，然而现在的问题的，最近半年来，我的大部分精力，甚至包括很多加班的时间，都越来有多地被牵制在人肉处理琐事上，我反而没有精力去自动化琐事，去消灭琐事了！
关于oncall
- 技术支持、服务器配置错误、报警处理、工单处理等等工作，这些工作谷歌并没有什么黑客气让它们消失了，只是用各种方法将它们的处理成本降低到了可接受范围内。
区别就在于oncall的压力吧，1）因为报警处理自动化、监控准确性、报警准确性等等基础设施不够完善，导致oncall的压力是很大的，sla报警可能经常触发，甚至导致“狼来了”效应，就像现在大数据相关服务的sla报警我已经习惯了；2）内部平台像是发布系统、工单系统、SSH权限等等多多少少会有小毛病，这些问题的支持很耗人；3）报警或问题发生之后的处理手段也不够好用，像是最近频繁出现的单实例问题，都是靠人肉重启去解决的，而且问题有越来越多的趋势，然而却没看到哪个团队在重点解决，似乎人肉cover住就可以先不管了；4）因为害怕故障发现不及时，同时还在接收很多业务报警、系统底层报警，但是因为业务报警的策略调整权在业务方
关于故障处理
- post-mortem，事后故障复盘
- 对事不对人，建立故障应急处理流程
这部分是我们团队一直在做的，故障复盘、故障监控发现率建设、故障todo跟进；但是因为故障是和KPI挂钩的，大家在处理故障时，还是会不知不觉跑偏到到底是谁的锅这个问题上，尤其是没有立刻现场复盘的故障。
SRE成为不同团队建的纽带
- SRE对公司内部的各种工具、轮子接触的比较多，能够帮助不同团队之间的工具传播
这个是事实，不过并没有作为一件事情来做，就像我对公司内部的服务发现、监控配置、压测平台、发布系统等等工具都是比较熟悉的，平常也会去帮助解答RD的这块疑问。但是，因为时间精力问题，很多细节的东西没有去深入了解，没法在这件事上获得更多收益。
What kind of coding do a typical SRE do?
- 没有typical SRE，不同方向的SRE做的coding差别很大；
- 故障预测，容量水位。也即现有监控数据的基础上，完善自动化监控；
- DBA SRE，协助开发相关系统，这块没太听明白，算是比较专的领域；
- 自动化配置，内部系统优化，这也是消灭琐事的一部分；
Coding部分对负责不同岗位的SRE来说是不一样的，硬要从技术难度上做区分，差别也很大，相通点就是在用代码解决运维问题吧。
这部分是我最想做的事情，却也是目前最少做的事情。我希望看到的世界是这样的，我在做一线运维工作，我是这个系统的直接使用者，我向其他团队推广这个系统，如果碰到了问题，我能够（有权利、有时间、有能力）去修复这个问题；而不是像现在这样，靠人工接入人肉维护系统的正常运转（包括CMDB、SSH授权、发布系统），却没有时间去做修复的事情，这就好像整个团队中的脏活累活我们包了，但是背后可以有成长、有收益的活却没有精力去做，只能拱手让人，这样真的会让人找不到成就感，找不到价值感。
我不想这样，我不要这样。
原文地址：https://www.cnblogs.com/carlsplace/p/11832579.html