离开前家公司，快半年了。
经常有人在qq或者mail或者电话问我，说是想去我前家公司，问我前家公司怎么样。说实话，我很理解，去一家公司之前，先了解下这个公司的心态，如果我处在他们的位置，我也会找个人问的。
但是，也请谅解，我不会对前家公司的任何事情作出任何的评论。任何事情，冷暖自知，如果我说好，你去了，感觉不好，会回过头来骂我；如果我说不好，你没去，结果后悔，这个责任也是我不能承受的。
而且，站在我的角度，我也不知道应该说好，还是说不好。说好，人家会问，那你为啥离职？说不好，人家会说，那你怎么还待了靠近三年。
还是那句话，冷暖自知！！！
业务连续性管理（Business Continuity Management，简称BCM），是一项综合管理流程，它使企业认识到潜在的危机和相关影响，制订响应、业务和连续性的恢复计划，其总体目标是为了提高企业的风险防范能力，以有效地响应非计划的业务破坏并降低不良影响。
BCM规划与实施包括企业信息系统的基础数据、应用系统与业务的灾难备份与恢复计划。
BCM一共有六个大的步骤，分别是：
BCM范围识别，其主要目的是识别关键的业务和资源（这个部分非常关键，如果这个部分出现偏差，则会导致整个BCM偏差）；
BCM风险分析，其主要目的是分析业务中断时的影响，这里有两个非常关键的概念，MTPD，最大可容忍的业务中断时间；RTO，恢复目标时间；这个部分也称为BIA，如果这个部分分析错误，则会导致整个BCM失败（这个部分很关键，BIA部分也是整个BCM部分最难的）；
BCM策略，主要是完成总体业务持续管理策略，活动选择性策略以及资源层的整合；在这个部分要考虑PPTISSC（这个部分是BCM的金团队，也就是老板们决定的事情）；
BCM反应和计划，也就是BCP过程，基于BCM策略，业务影响分析，风险评估和BCM策略，开发和执行适当的BCM计划和安排（这个部分需要无数的文档来完成，也是整个BCM过程中最累的部分）；
后面两个步骤是BCM培训和维护，就比较简单点了。
BCM的一切都是基于假想的，BCM关注的是关键业务中断的时候，所采取的措施。
对于一个互联网企业，其关注的应该是能引起关键业务中断的事件的管理。例如，IDC机房整体瘫痪，员工群发性自杀，工作所在地发生严重的自然灾害等情况。平时的容灾呀，备份呀考虑的层面应该都小于BCM。
BCM和风险管理有着本质的区别，其区别主要在于：
（下图摘自DNV在BCM培训中的部分，版权属于DNV）
需要记住的是，BCM关注于业务的恢复，而不是业务为什么发生中断，一般来说，BCM的启动都是基于事件已经发生，而不是事件可能发生。
IE8，登录支付宝，准备进行信用卡还款，连续三次都是下面这个界面
看看这到底是个啥垃圾？？？？？？？？？？？？？？？？？？？？？？？
入职靠近四个月的时候，正式启动了我的转岗流程。
从预研部的高级DBA转岗到研发部-运维的职位，从P线转岗到M线。不知道以后会累成啥样了。
世界杯开幕了，相信很多人会去看世界杯。
可是偶，对足球一窍不通，只能看别人狂欢了。
或许这一个月，是很多人的盛宴，我就可以好好工作了，嘿嘿，希望晚上不要被看球的人吵醒。
今天得到lori的消息，他也报名参加ocm考试了。
以前我们在zmcc团队一共四个人，我，alan，lori，doris。去年11月，我通过了ocm考试，后来由于种种原因，今年的3月选择了离开那个团队。
如果他们三个一起考过，那应该是这个team原来的四个人全部都是ocm了，也是可以让我自豪的事情了。
在此，预祝他们，一次全部通过。
今天不知道怎么了，在windowns 7上安装mysql，就是不成功，后来没有办法去，在http://dev.mysql.com/downloads/mysql/下了个免安装的版本，解压后，用是能用了。
给应用测试的人建立了一个测试的数据库和用户，奇怪的是，在本地登录没事，远程登录，无论如何都报10045（28000）错误。
C:\Windows\system32>mysql -uuism -h 172.16.9.43
ERROR 1045 (28000): Access denied for user ‘uism’@’172.16.5.20′ (using password:
YES)
检查系统的user表，发现结果如下：
mysql> select user ,host ,password from user;
+——+———–+——————+
| user | host | password |
+——+———–+——————+
| root | localhost | |
| root | 127.0.0.1 | |
| | localhost | |
| uism | localhost | 16cfa8943c7fb191 |
| uism | % | |
| uims | % | |
+——+———–+——————+
6 rows in set (0.00 sec)
用户在本地登录是好的，远程无论如何都不行，不管给不给密码。查询网络发现，需要将user表中那个用户名为空的用户干掉；
mysql> delete from user where user is null;
Query OK, 0 rows affected (0.00 sec)
mysql> delete from user where user =”;
Query OK, 1 row affected (0.00 sec)
这里看看，原来这个用户名还不是null，只是一个空字符串，晕倒。
然后，重新更新下权限，
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
再在客户端做链接：
C:\Windows\system32>mysql -uuism -h172.16.9.43
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 103
Server version: 5.1.47-community MySQL Community Server (GPL)
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
mysql>
Mysql怎么会有这么搞笑的问题，哈哈，而且那个用户的host为%的那个，密码为空，现在变成了远程不需要密码，本地需要密码，囧！
上周五开始，每天下午靠近四点有蛋糕吃，而且上周五开始有西瓜，不过人太多，上周差点没抢到。
今天下午，居然是公司的pp行政来一个一个的发，每人一份西瓜和蛋糕。
下面是这两吃的的图片，加入我们吧，天天上班吃蛋糕和西瓜：）
今天开始处理我们的后台数据库中的一个mysql的问题，问题症状是，每天有个不固定的时间，整个系统的sql执行会非常慢，如果你不理他，过会就自己好了。
简单分析了下，那个系统就两个表，被设计成了mysql cluster模式。
在slow log中有如下内容：
………
Count: 3568 Time=0.00s (0s) Lock=0.00s (0s) Rows=0.0 (0), session[session]@localhost # Query_time: N.N Lock_time: N.N Rows_sent: N Rows_examined: N SET timestamp=N; select * from session where sky_id=N
Count: 284 Time=0.00s (0s) Lock=0.00s (0s) Rows=0.0 (0), session[session]@localhost # Query_time: N.N Lock_time: N.N Rows_sent: N Rows_examined: N SET timestamp=N; delete from session where sky_id=N
Count: 690 Time=0.00s (0s) Lock=0.00s (0s) Rows=0.0 (0), session[session]@localhost # Query_time: N.N Lock_time: N.N Rows_sent: N Rows_examined: N SET timestamp=N; insert into session(sky_id, user_name, nick_name, nick_name1, gender, age, portrait_id, token, province, city, pos_code, pos_desc, acc_esbaddr, acc_session_index, acc_type, ip, alive_check, rand_tag, last_oltime, logintime) values(N, ‘S’, ‘S’, ‘S’, N, N, N, N, ‘S’, ‘S’, N, ‘S’, N, N, N, ‘S’, N, N, N, N)
Count: 1572 Time=0.00s (0s) Lock=0.00s (0s) Rows=0.0 (0), session[session]@localhost # Query_time: N.N Lock_time: N.N Rows_sent: N Rows_examined: N SET timestamp=N; select * from session where sky_id in (N,N)
………………..
这段代码看，执行慢最多的sql居然是在session表上的，看看session表的结构
mysql> desc session;
+——————-+———————+——+—–+———+——-+
| Field | Type | Null | Key | Default | Extra |
+——————-+———————+——+—–+———+——-+
| sky_id | int(10) unsigned | NO | PRI | NULL | |
| user_name | char(32) | NO | | NULL | |
| nick_name | char(32) | YES | | NULL | |
| nick_name1 | char(64) | YES | | NULL | |
| gender | tinyint(1) | YES | | NULL | |
| age | int(10) unsigned | YES | | NULL | |
| portrait_id | int(10) unsigned | YES | | NULL | |
| token | int(10) unsigned | YES | | NULL | |
| province | char(32) | YES | | NULL | |
| city | char(32) | YES | | NULL | |
| pos_code | int(10) unsigned | YES | | NULL | |
| pos_desc | varchar(64) | YES | | NULL | |
| acc_esbaddr | int(10) unsigned | YES | | NULL | |
| acc_session_index | int(10) unsigned | YES | | NULL | |
| acc_type | tinyint(3) unsigned | YES | | NULL | |
| ip | char(15) | YES | | NULL | |
| alive_check | int(10) unsigned | YES | | NULL | |
| longitude | int(11) | YES | MUL | NULL | |
| latitude | int(11) | YES | MUL | NULL | |
| loc_desc | varchar(64) | YES | | NULL | |
| rand_tag | int(11) | YES | MUL | NULL | |
| mid | varchar(256) | YES | | NULL | |
| last_oltime | int(11) | YES | | 0 | |
| logintime | int(11) | YES | | 0 | |
+——————-+———————+——+—–+———+——-+
24 rows in set (0.05 sec)
可以看出，sky_id上是主键。
再看看这个执行最慢的几个sql的执行计划：
mysql> explain select * from session where sky_id=112414853 \G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: NULL
type: NULL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: NULL
Extra: Impossible WHERE noticed after reading const tables
1 row in set (0.00 sec)
ERROR:
No query specified
mysql>
mysql>
mysql> explain select * from session where sky_id in (112414853,-1,-1) \G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: session
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 2
Extra: Using where with pushed condition
1 row in set (0.00 sec)
ERROR:
No query specified
资深开发DBA
工作地点：杭州
技能要求:
1.精通SQL代码编写
2.熟悉SQL优化
3.精通数据库建模
4.良好的沟通技能、团队合作能力
5.具有良好的数据建模能力
6.掌握数据库开发与设计工具的使用
7.三年以上开发DBA工作经验
8.至少熟悉掌握ORACLE/POSTGRESQL/MYSQL中的一种
9.有开发经验者优先
工作职责:
1.负责 DB 开发、以及开发/测试库的日常维护；
2.负责 DB Schema 设计以及评审；
3.完善和宣贯 DB 开发规范和相关流程，提高应用开发人员 DB 开发技能。
4.评估，跟踪，支持开发项目
5.数据库变更管理
6.数据库开发相关性能优化
7.开发、测试环境管理与维护
这个岗位的人，我会亲自带，目前隶属在公司最为核心的研发部门。发展机会非常不错，目前定位是资深开发dba，目标定位是开发dba主管，有兴趣的人，给我简历。
guoyue@gmail.com