Limoncelli的测试：

• A.面向公众的处理方式:
  • 1.有没有通过项目管理系统对用户请求进行跟踪？
  • 2. “三大授权策略”是否经过具体定义并加以发布？
  • 3.整个团队的运行状态每月是否依各细则指标加以衡量并备案？
• B. 现代化团队处理方式:
  • 4.你在维基词条中是否具备独特的“策略及流程”类说明？
  • 5.日常所采用的密码安全性有保障吗？
  • 6.技术团队的代码是否处于源码控制系统的监管之下？
  • 7.你的团队有没有使用bug跟踪系统？
  • 8.在你的bug/项目管理方面，稳定性问题的优先级是否高于新功能？
  • 9.你的团队有坚持记录“设计文档”的习惯吗？
  • 10.一旦发生问题，有没有一套机制专门用于记录故障信息？
• C. 业务操作方式:
  • 11.每项具体服务都具备操作文档吗？
  • 12.每项服务是否都得到了适当的监管？
  • 13.你有没有部署过寻呼轮换机制？
  • 14.业务流程中是否具备彼此独立的开发、质量保证以及生产系统？
  • 15.在某套方案进行大范围推广前，有没有事先进行过必要的试点？
• D. 自动化处理方式:
  • 16.有没有在业务中使用到类似cfengine、puppet以及chef之类的配置管理工具？
  • 17.任务自动管理机制是否在身份账户的制约下进行？
  • 18.电子邮件的自动化生成处理是不是只在必要时启动，而非靠满纸荒唐言来拼凑使用率？
• E. 团队管理方式:
  • 19.有没有一套专门的数据库用来管理所有计算机设备？
  • 20.操作系统安装是否达到了完全自动化？
  • 21.整个团队中的软件升级及补丁更新是否做到了自动化处理？
  • 22.有没有一套完整的硬件更新规章？
• F. 硬件发生故障时的处理方式:
  • 23.当某块硬盘发生问题时，你的整套服务器体系能否继续运作？
  • 24.网络核心有没有做到N+1？
  • 25.你的备份工作是自动完成的吗？
  • 26.有没有定期测试灾难恢复方案的制度或计划？
  • 27.你数据中心内的设备具备远程电源/控制台访问功能吗？
• G. 安全性处理方式:
  • 28.业务中所用到的台式机、笔记本电脑以及服务器是否运行着自动更新且无需确认提示的反恶意软件？
  • 29.企业中是否向员工下发了书面的安全性规章制度？
  • 30.你有没有对所有相关领域进行周期性的安全审查？
  • 31.是否有相关机制允许管理者在一小时内关闭所有用户账户？
  • 32.是否有相关机制允许管理者在一小时内改变所有特权（主控）密码？

【编辑推荐】

1. 自动监控从MySQL同步的脚本
2. Nagios远程监控软件的安装与配置详解
3. Linux监控工具的展览馆

目前也在做云平台相关的工作，找到了这篇关于云平台超售的文章，对于计算超售的过程还不是特别了解，转到小站方便研究。作者是 阿里云高级产品专家 realzyy，以下是原文https://zhuanlan.zhihu.com/p/24435587.：

2016年10月26日，IT之家的CEO发布了一则公告（参见《完成阿里云至百度云站点迁移工作》），其中抱怨阿里云ECS云服务器超卖严重且售后态度不积极的内容引发了整个云计算圈子激烈讨论。 随后的一天，袋鼠云的CTO在云栖社区上发声（参见《IT之家，这不是个案》），指出IT之家的技术架构落后，使用云计算的“姿势不对”是导致整个事件最主要的原因。

-—————————– 为了避免草率得出结论，我们先使用理论数据推演。首先定义超卖率（OverSaleRate）：

假设一台物理主机有16个物理CPU+256GB内存，且其中内存是限定资源。另有假设平均的云服务器规格为2vCPU+4GB的内存，则CPU超卖率有如下推导：

这意味着，当内存售卖率（LimitedResourceSaleRate）为10%时CPU是不超卖的，当内存售卖率为60%时CPU超卖率是380%，当内存售卖率为80%时CPU超卖率则达到了540%。

-—————————– 在上述的假设条件下，云计算的CPU超卖程度显然是比较夸张的。那么实际情况是怎么样的呢？为了避免口水战，我们使用全球最大的云计算厂商AWS的官网数据来进行验证。 首先是根据EC2专用主机和EC2实例的配置，推测EC2物理主机的配置：

1. 通用型t2、m3、m4三个系列的内存／vCPU比例为0.5、1、2、4
2. 计算优化型c3、c4两个系列的内存／vCPU比例为2
3. 内存优化型r3、r4两个系列的内存／vCPU比例为8（x1系列比较特殊，略去）

相应的，我们从这个表里面能获取到的关键信息是什么呢？

1. 假设只有c3和c4系列的EC2实例是对应分布在c3和c4类主机上的，则c3和c4主机不存在CPU超卖
2. 假设只有r3和r4系列的EC2实例是对应分布在r3和r4类主机上的，则r3主机不存在CPU超卖，而r4主机存在少量CPU超卖
3. 假设只有m3和m4系列的EC2实例是对应分布在m3和m4类主机上的，则m3主机不存在CPU超卖，而m4主机存在少量CPU超卖
4. t2系列的EC2实例没有任何主机型号与之直接对应，而t2型的内存／CPU比例非常低（0.5-2），是造成CPU超卖的元凶

在此不妨做一个推测，AWS的EC2实例分配策略基于三条逻辑：

1. c3、c4、r3、r4、m3、m4等EC2规格分布在对应类型的主机上
2. t2系列中的2vCPU+8GB、4vCPU+16GB、8vCPU+32GB三个规格分布在m3、m4主机上
3. t2系列中的1vCPU+0.5GB、1vCPU+1GB、1vCPU+2GB、2vCPU+4GB四个规格分布在CPU比较空闲的主机上，并会有定期的调度策略保证物理CPU最大程度上的平均利用

在这三条逻辑的保障下，AWS可以在t2实例数量较少的情况下将超卖比控制在非常低的水位上，让用户基本对CPU超卖没有感知。在t2实例数量特别多的情况下，超卖比则会迅速恶化至500%、1000%，甚至2000%。

那么是否可能专门为t2系列定制一款主机，保证超卖在理论上就不会发生？我想AWS应该是可以做到的，但是主机成本将会非常高昂，跟t2系列低价的卖点将会背道而驰。

-—————————–

回到最初的问题：

云计算的虚拟化是否就一定存在着资源超卖，因此不能满足大企业的稳定性需求？

答案已经非常明显了，请大家自行脑补吧。

重装了系统，登陆的时候提示无法登陆。

以前的做法，都是直接把 known_hosts 删除了事。由于现在记录的太多了，删除掉会又问题。随意添加了几个反斜杠，就成功了：

ssh-keygen -f "/root/.ssh/known_hosts" -R \[103.71.xxx.xxx\]\:xxx

显示删除成功

Host [103.71.xxx.xxx]:xxx found: line 4 type ECDSA 
/root/.ssh/known_hosts updated. 
Original contents retained as /root/.ssh/known_hosts.old

这篇文章只列出一些点和代码，作为手册用，不做过多描述。

什么是内网穿透

转自百度百科：

内网穿透，即NAT穿透，网络连接时术语。计算机是局域网内时，外网与内网的计算机节点需要连接通信，有时就会出现不支持内网穿透。内网穿透，就是能让外网的电脑找到处于内网的电脑。

网络上比较有名的商业产品是花生壳。个人使用的话可以使用frp自建，详细过程请看下文。

frp server

docker run -itd --name frps --net=host --restart=always -v /var/local/frp/frps.ini:/tmp/frps.ini alexzhuo/frp /usr/bin/frp/frps -c /tmp/frps.ini

frps.ini内容大致如下：

[common]
bind_addr = 0.0.0.0
bind_port = 7000
vhost_http_port = 80
vhost_https_port = 443
dashboard_port = 7500
# dashboard 用户名密码可选，默认都为 admin
dashboard_user = admin
dashboard_pwd = admin

[ssh]
type = tcp
auth_token = 123
bind_addr = 0.0.0.0
listen_port = xxx

[web]
type = http
custom_domains = frp.test.org
auth_token = 123

frp client

#!/bin/bash

mkdir -p /var/local/frp
cd /var/local/frp

cat <<EOF > frpc.ini
[common]
server_addr = xx.xx.xx.xx
server_port = 7000
auth_token = 123

[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22

[web]
type = http
local_port = 8080
EOF

docker run -itd --name frpc --net=host --restart=always -v /var/local/frp/frpc.ini:/tmp/frpc.ini alexzhuo/frp /usr/bin/frp/frpc -c /tmp/frpc.ini

这是一篇，很古老的文章。。。。。然而这又是一篇和我blog有着一些联系的文章。。。我blog右边的播放器，其实就是来源于此文。

鉴于互联网上消失的人越来越多，为了给自己留个纪念，把他这篇文章转载过来做个留念。

作者现在仍然活跃在前端开发的技术栈中，可以参考他的github@tommy351

寒假即将结束，不巧膝盖突然中了一箭，便决定实验 HTML5 audio标签的效果，虽然已有 jPlayer 这款轻便好用的播放器，但不折腾一下就没办法消磨时间了，所以本次的实验品完全由我操刀。

开始之前

首先必须了解 audio 标签的使用方式：

<audio controls>
  <source src="music.mp3">
  <source src="music.ogg">
</audio>

输入以上代码后，便可在网页中看到浏览器内建的播放器。每种浏览器支援的播放类型不一，最保险的方法是备妥mp3、ogg。

为了浪费时间，当然不可能用浏览器的预设介面，所以删除controls属性，透过 JavaScript 操作：

var audio = document.getElementsByTagName('audio')[0];
// 播放
audio.play();
// 暫停
audio.pause();

只需要懂这两个函数，就可製作最基础的播放器了，其他複杂的指令可参阅文末的参考出处。

介面

写网页时，比起最重要的 JavaScript，我习惯先写 CSS，最初的参考范本是 Mac 的 CoverFlow。

经过一连串绞尽脑汁，写了一堆乱七八糟的 CSS 之后，成品如下。

无论是倒影、中间的圆圈进度表都与 CoverFlow 非常相像，但这种样式实在 太麻烦了 不便使用者操作，所以从 Premium Pixels 偷点子过来，稍微加油添醋一下，完成了播放器介面 Ver. 2。

Ver.2 与 Ver.1 完全不像？这种事情不重要啦！

##核心

介面完成自爽一下之后，就得面对麻烦的 JavaScript 了，播放、暂停非常简单，按钮按下去执行乡对应的动作即可，然而音量调整与进度条该如何处理呢？

虽然本次的重点是消磨时间，但再去造一个轮子实在他妈的太累了，于是 聪明如我 请到了 jQuery UI，Slider 功能压缩后需要约 20KB 的空间，有点庞大不过方便就好。

时间的控制方式如下，单位为秒数，例如跳至第 100 秒的位置：

audio.currentTime = 100;

音量的控制方式如下，范围为 0~1，例如将音量调整至一半大小：

audio.volume = 0.5;

audio可绑定play, pause, ended, progress, canplay, timeupdate等事件。play与pause如字面上意思，分别为播放、暂停后生效。

audio.addEventListener('play', function(){
  play.title = 'pause';
}, false);

audio.addEventListener('pause', function(){
  play.title = 'play';
}, false);

ended为结束后生效，当音乐结束后，可透过此事件让时间归零。

audio.addEventListener('ended', function(){
  this.currentTime = 0;
}, false);

当音乐档桉开始载入后，便会启动progress事件，可透过此事件监测下载进度。Firefox 可能会发生问题，建议搭配durationchange事件使用。

audio.addEventListener('progress', function(){
  var endVal = this.seekable && this.seekable.length ? this.seekable.end(0) : 0;
  buffer.style.width = (100 / (this.duration || 1) * endVal) + '%';
}, false);

当音乐下载到一定程度后，canplay事件便会生效，一般会透过此事件初始化播放器。相同类型的事件还有很多，依照启动顺序分别为：loadstart, durationchange, loadeddata, progress, canplay, canplaythrough。

timeupdate会在音乐播放时不断生效，可透过此事件更新时间。

audio.addEventListener('timeupdate', function(){
  progress.style.width = (this.currentTime / this.duration) * 100 + '%';
}, false);

##播放列表

一个播放器的基础功能就此完成，能够播放、暂停、调整音量、调整时间。但这显然还不够，播放列表对于播放器而言相当重要。（大概啦）

不要吐槽为啥播放列表裡全是动漫歌，林北就是宅啦…

与自己的逻辑奋战大约一晚后，有播放列表、随机播放、重複播放（单首、全部）功能的播放器于焉完成。只需要 214 行、约 6KB 的代码（未压缩）即可完成，应该能算是轻便简易了。

##后记

播放列表的製作过程有点髒，中途还重构了几次，所以直接看范例应该会比较快，若对于范例内的程式码感到疑惑，可在下方留言。

范例内已设定了一些参数，可在js/script.js内更改。第 5 行的continous参数为连续播放，第6行的autoplay参数为自动播放，第7行的playlist阵列请自行设定，压缩档内不会附带范例内的音乐档桉。playlist阵列的格式如下：

var playlist = [
  {
    title: 'Tell Your World',
    artist: 'livetune feat.初音ミク',
    album: 'Tell Your World',
    cover: 'cover/tell_your_world.jpg',
    mp3: 'music/tell_your_world.mp3',
    ogg: 'music/tell_your_world.ogg'
  }
];

title为标题，artist为演出者，album为专辑名称，cover为专辑封面的路径，mp3、ogg分别为音乐档桉的路径，建议备妥两种格式的档桉，要不然 Firefox 和 Opera 不就只能去死了吗？

因为做到最后头脑快爆炸了，懒得做 Flash fallback，IE 请去死一死吧。

下载

##参考出处

• jPlayer
• 小試HTML 5 audio - 黑暗執行緒
• Using HTML5 audio and video - MDN

• [HTML5 Audio and Video: What you Must Know

  Nettuts+](http://net.tutsplus.com/tutorials/html-css-techniques/html5-audio-and-video-what-you-must-know/)

• [Free PSD: Compact Music Player

  Premium Pixels](http://www.premiumpixels.com/freebies/compact-music-player-psd/)