[原创]公司升级服务器小结 Post By：2011-4-2 13:23:44 Post IP：113.97.200.226
易经有云万事万物相关性。
你能想到，俩会会影响到海外通道吗？ 这八竿子打不着的东西。我们遇上了。
去联通机房下线服务器，联通理由；俩会维稳 封网。封就封吧，好在钱也交了；就折腾到月底吧。正好，这期间，我们也在测试mysql数据库并发情况。
在期间发生了些事情
总结如下：
1） 商务失职 责任心不强
第一次割接出现下行失败问题 大概1000多条 。是因海外没有严格依据ip鉴权 当时列出一些通道失败情况要求商务跟进解决 （没人跟进）
这直接为第2次切换埋下了隐患。
2） 海外商务应急能力差
第2次切换是ip临时公布的我人在机房 。海外反映迟钝，说客户睡觉云云。这事同样发生在我们之前；原ip是临时发现部分国家不通；机房请求我们更换ip。包括mail dns 都是临时换的。就是跟时间赛跑，抢收入。能抢回多少抢回多少，dns 2小时生效；之前也是ip地址接口；后汲取教训改用域名接口。管你客户是在睡觉干啥。都是电话联系，不到2小时搞定，唯一一家没搞定的是量比较少。发邮件了；当时没保留对方电话，哪个也是3小时对方上班后看到邮件搞定的。
反观，差距如此明显。最重要是责任心不强。出了问题，我可以推卸责任。往技术上推，你没提前通知我。呵呵呵，无语。
3）海外商务只是传话筒
在跟国外客户解析ip鉴权问题，换域名问题 好像这些是只是技术问题 。商务不过问细节。
在这之前商务同样的问题，他们会想，dns是什么东西。为何要用dns,为何要加ip鉴权 弄清所以然。而我们呢？一个问题要翻来覆去解析，自己不会google?
这两天烦得我牙疼。
4）公司职责不清 ，赏罚不分明
这是最大的问题。说白了；没有跨部门之间的调度权限 ，没有奖罚分明的权利。 比如升级服务器问题。如果赋予我奖罚分明的权利。
对应怠慢，消极者开除权限，谁敢不听？对应尽职为公司服务的就应该奖励，徐楠晚上为赶进度，在家加班00：00 测试mysql服务器；
所谓项目制，看起来是一个摆设。一定要立项目才叫项目制？
我说一句，商务会乐呵呵的回你10句。 就好比，一个将军没有指挥权。将军再大的神通也没用。
一个公司要做大，要敢于下放权限。
5）关于这次技术的切换问题的方案 回滚
这是正常的操作流程；我曾担任过139手机邮箱系统割接过程；曾先后7－10次通宵加班割接，无过错。而现在只是一个服务器的切换，岂能阴沟翻船？
比如第一次3月初割接失败， 回滚 。这是很正常的操作，不要大惊小怪。不出问题那叫神仙，这次出问题就是造成1000多条下行失败损失，后发现系统调度慢，立马回滚。
导致那次失败，主要是之前的那套mysql安装源码找不到了；徐楠从网上找到另外一个版本，而我事先也不知道。
之后，先后经历，jdk版本不同也同样问题。重新下载同一版本jdk ,wrapper.jar 版本又从.8服务器进行了同步。重新测试过各种版本服务器，都失败；然后，
我又决定让徐楠网上下了 同样版本的mysql源码编译安装搞定。这期间经历的困难可想而知。遇到这样的问题，没别的路，只能一步步排除法，排查。先后排查了jdk, wrapper.jar 环境；后排查了mysql . 好在，我们系统ppg模型有一个调度，能够自动现实执行数据库调度时间的日志，在做并发测试时，徐楠又找到一个小巧的java并发测试工具。为防止再出错，编译mysql源码过程中，我亲自编译。
经过测试，系统调度过程处理1条的时间是2－8ms 这个速度是日调度1亿级的处理速度，而目前线上的也是这速度。正好也验证了smg引擎的优良性。而在之前的没编译的mysql数据库 是3000－5000ms 1条。 速度提高了1000倍。而这一天，正是2011－03－31 最后一天了。好像，正在等待天时。万幸，所付出的努力终于获得了收获。
6） 多次切换原因
A) 2.28 日月末 第一次切换 当时目的希望为公司节省成本 （当月服务器搬迁 ，新机房送1一个月免费） ；后发现mysql版本不同，导致调度缓慢 第一次回滚
B) 3.4日 第2次切换 后更换mysql 但没编译（因3月4日扣款，仍希望节省成本） 后仍然发现调度缓慢 但箭在线上， 不得不发。当日早上，通知公司后勤 上 午要搬迁服务器 更换机房 。电话方知道，需要提前3天申请下线 （第一次遇到联通这么bt）;计划取消， 执行第2次回滚。
后因俩会延迟到15日 俩会结束 等审批（21－23日得通知，已经通过审批服务器下架，但期间，后台技术在抓紧修复测试mysql问题，又考虑到成本，反正钱已经支付，索性坚持到月底搬迁 ，这期间有节约成本考虑，更重要的技术仍然没找到mysql调度缓慢原因）
C) 3.30日凌晨 我在家里编译好，安排徐楠线上测试，虽然调度失败，但从执行时间来看处理时间是8ms 速度大大加快。调度失败是因为部分表，过程，没导入。 暂通知徐楠休息。第2天再搞 ；上午导入完整过程表，测试 调度成功，调度一条记录执行时间介于2－8ms 到达理想预期。至此，成功。上午切换，dns生效2小时 ，31日上午搬迁服务器，下午切换，期间商务多有配合不力，但总算无大过错；国内失败是因为忘记通知对方对新ip做鉴权 ，但影响不大，可顺利补发失败数据。
原计划更改239服务器ip ，更改理由 239，209 不能在外网ip 互访 。经过跟机房协商 等4台服务器到齐放1个机柜。但在实际运作过程发现，原来8,9服务器搬迁过来后，变为228,227 因分配的网段不同，可以互访 ；后又申请机房将209 （无业务）更换ip ,215 后，可以达到互访另外3台，故原计划撤销239（临时跑通道业务）的方案取消，这台服务器也没放在同一机柜（我们期望只要能达到4台服务器之间能够外网Ip互访即可）。
（ 这里有点小插曲，原来8,9两台服务器2U ;而我事先不知情； 后联系机房业务，因跟我之间有多次业务往来，后免去2U额外占机费。）
d) 3.31日 中午12:00 机房 在8，9 服务器分配Ip,后进行dns切换。经过测试大部分通道已经顺利割接，剩余1，2个小通道量不大 也在次日顺利割接。至此割接完成
7） 数据整合
预计 4.2－4.7日前， 会将3月来回切换的几个服务器数据整理回一个.8 (228)数据库服务器，重新生成美元账单。
易经有云万事万物相关性。
你能想到，俩会会影响到海外通道吗？ 这八竿子打不着的东西。我们遇上了。
去联通机房下线服务器，联通理由；俩会维稳 封网。封就封吧，好在钱也交了；就折腾到月底吧。正好，这期间，我们也在测试mysql数据库并发情况。
在期间发生了些事情
总结如下：
1） 商务失职 责任心不强
第一次割接出现下行失败问题 大概1000多条 。是因海外没有严格依据ip鉴权 当时列出一些通道失败情况要求商务跟进解决 （没人跟进）
这直接为第2次切换埋下了隐患。
2） 海外商务应急能力差
第2次切换是ip临时公布的我人在机房 。海外反映迟钝，说客户睡觉云云。这事同样发生在我们之前；原ip是临时发现部分国家不通；机房请求我们更换ip。包括mail dns 都是临时换的。就是跟时间赛跑，抢收入。能抢回多少抢回多少，dns 2小时生效；之前也是ip地址接口；后汲取教训改用域名接口。管你客户是在睡觉干啥。都是电话联系，不到2小时搞定，唯一一家没搞定的是量比较少。发邮件了；当时没保留对方电话，哪个也是3小时对方上班后看到邮件搞定的。
反观，差距如此明显。最重要是责任心不强。出了问题，我可以推卸责任。往技术上推，你没提前通知我。呵呵呵，无语。
3）海外商务只是传话筒
在跟国外客户解析ip鉴权问题，换域名问题 好像这些是只是技术问题 。商务不过问细节。
在这之前商务同样的问题，他们会想，dns是什么东西。为何要用dns,为何要加ip鉴权 弄清所以然。而我们呢？一个问题要翻来覆去解析，自己不会google?
这两天烦得我牙疼。
4）公司职责不清 ，赏罚不分明
这是最大的问题。说白了；没有跨部门之间的调度权限 ，没有奖罚分明的权利。 比如升级服务器问题。如果赋予我奖罚分明的权利。
对应怠慢，消极者开除权限，谁敢不听？对应尽职为公司服务的就应该奖励，徐楠晚上为赶进度，在家加班00：00 测试mysql服务器；
所谓项目制，看起来是一个摆设。一定要立项目才叫项目制？
我说一句，商务会乐呵呵的回你10句。 就好比，一个将军没有指挥权。将军再大的神通也没用。
一个公司要做大，要敢于下放权限。
5）关于这次技术的切换问题的方案 回滚
这是正常的操作流程；我曾担任过139手机邮箱系统割接过程；曾先后7－10次通宵加班割接，无过错。而现在只是一个服务器的切换，岂能阴沟翻船？
比如第一次3月初割接失败， 回滚 。这是很正常的操作，不要大惊小怪。不出问题那叫神仙，这次出问题就是造成1000多条下行失败损失，后发现系统调度慢，立马回滚。
导致那次失败，主要是之前的那套mysql安装源码找不到了；徐楠从网上找到另外一个版本，而我事先也不知道。
之后，先后经历，jdk版本不同也同样问题。重新下载同一版本jdk ,wrapper.jar 版本又从.8服务器进行了同步。重新测试过各种版本服务器，都失败；然后，
我又决定让徐楠网上下了 同样版本的mysql源码编译安装搞定。这期间经历的困难可想而知。遇到这样的问题，没别的路，只能一步步排除法，排查。先后排查了jdk, wrapper.jar 环境；后排查了mysql . 好在，我们系统ppg模型有一个调度，能够自动现实执行数据库调度时间的日志，在做并发测试时，徐楠又找到一个小巧的java并发测试工具。为防止再出错，编译mysql源码过程中，我亲自编译。
经过测试，系统调度过程处理1条的时间是2－8ms 这个速度是日调度1亿级的处理速度，而目前线上的也是这速度。正好也验证了smg引擎的优良性。而在之前的没编译的mysql数据库 是3000－5000ms 1条。 速度提高了1000倍。而这一天，正是2011－03－31 最后一天了。好像，正在等待天时。万幸，所付出的努力终于获得了收获。
6） 多次切换原因
A) 2.28 日月末 第一次切换 当时目的希望为公司节省成本 （当月服务器搬迁 ，新机房送1一个月免费） ；后发现mysql版本不同，导致调度缓慢 第一次回滚
B) 3.4日 第2次切换 后更换mysql 但没编译（因3月4日扣款，仍希望节省成本） 后仍然发现调度缓慢 但箭在线上， 不得不发。当日早上，通知公司后勤 上 午要搬迁服务器 更换机房 。电话方知道，需要提前3天申请下线 （第一次遇到联通这么bt）;计划取消， 执行第2次回滚。
后因俩会延迟到15日 俩会结束 等审批（21－23日得通知，已经通过审批服务器下架，但期间，后台技术在抓紧修复测试mysql问题，又考虑到成本，反正钱已经支付，索性坚持到月底搬迁 ，这期间有节约成本考虑，更重要的技术仍然没找到mysql调度缓慢原因）
C) 3.30日凌晨 我在家里编译好，安排徐楠线上测试，虽然调度失败，但从执行时间来看处理时间是8ms 速度大大加快。调度失败是因为部分表，过程，没导入。 暂通知徐楠休息。第2天再搞 ；上午导入完整过程表，测试 调度成功，调度一条记录执行时间介于2－8ms 到达理想预期。至此，成功。上午切换，dns生效2小时 ，31日上午搬迁服务器，下午切换，期间商务多有配合不力，但总算无大过错；国内失败是因为忘记通知对方对新ip做鉴权 ，但影响不大，可顺利补发失败数据。
原计划更改239服务器ip ，更改理由 239，209 不能在外网ip 互访 。经过跟机房协商 等4台服务器到齐放1个机柜。但在实际运作过程发现，原来8,9服务器搬迁过来后，变为228,227 因分配的网段不同，可以互访 ；后又申请机房将209 （无业务）更换ip ,215 后，可以达到互访另外3台，故原计划撤销239（临时跑通道业务）的方案取消，这台服务器也没放在同一机柜（我们期望只要能达到4台服务器之间能够外网Ip互访即可）。
（ 这里有点小插曲，原来8,9两台服务器2U ;而我事先不知情； 后联系机房业务，因跟我之间有多次业务往来，后免去2U额外占机费。）
d) 3.31日 中午12:00 机房 在8，9 服务器分配Ip,后进行dns切换。经过测试大部分通道已经顺利割接，剩余1，2个小通道量不大 也在次日顺利割接。至此割接完成
7） 数据整合
预计 4.2－4.7日前， 会将3月来回切换的几个服务器数据整理回一个.8 (228)数据库服务器，重新生成美元账单。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
