终于知道和ATC协调是多么的难

我知道今天对于中国来说是一个重要的日子,神七要发射了,航天员要出舱。但对于每一个在地上的老百姓来说,今天还是普通的一天。
早上接班时,2577滑回了。我上次下班时就有一个滑回交给下一个班,今天被我碰上了。出来混是要还的。2577的自动增压系统故障是老毛病了,上周也被我碰到过一次。今天机务说按MEL走,一套故障,还有自动的另一套,没问题。第二次滑出起飞后,空中报告两套自动增压系统都坏了,只能用人工方式。去程是没问题了,但是回程安MEL双自动增压不工作的条款放行的话,就要求载客在10000ft一下飞行了。
没办法,只能开始漫长的ATC协调。
我拿出航图,检查回程的航路是否允许10000一下飞行,济南回上海最高度网格高度也就1000多米,选择2700的飞行高度层是没问题的。从航图上找到经过的管制区,一个个的打电话,申请2700这个高度。我依次打了:总局总调,济南站调,济南区调,上海区调。其中,总局总调表态只要地方管制部门同意我就同意。其余几个部门都同意了,而且济南区调和上海区调都说他们本身没有问题,而且帮忙也询问了军方表示同意。正当我打算给总局总调报告地方上都同意的时候,上海的管调来电话了,说是不同意,说军方有活动,而且说是总局总调的人说不同意的。我就纳闷了,我打给总局问,接电话的人口气粗暴,说我跟他协调的时候没有说过要2700这个高度,他只同意了飞机回来,但没有同意这么低的高度。我靠,我一个正班航班正常高度回来还用的着给你总局申请啊,找你总局当然是要低高度罗,我怎么会没说过2700这个高度呢。
晚上回到家,神七发射成功了。听说去太原的航班返航了,因为济南以外的地方都禁航,半个中国不能飞了。

防滞刹车不工作时不能使用自动刹车

早上2913起飞后报告,客舱增压系统故障了,自动跳到备用方式去了,QRH上没有要求操作的项目。737的客舱增压有两套自动系统,两套都可以独立工作,如果都坏了,就要用人工方式控制外流活门的位置。之后的航段都按照MEL:21-15 自动增压系统放行,只要人工方式保证可用就行了。
下午一架767的防滞在空中出现了故障,机务瞎说防滞坏了可以用自动刹车的,后来我们查了AFM:防滞刹车不工作时不能使用自动刹车

第一个ETOPS计划

月底就要开塞班岛航线了,今天上班时被要求练习ETOPS操作程序。所以就做了我的第一个ETOPS计划。
不要小看它。。。这一个计划就要被收费50块钱~~~它算是一个身价比较高的txt文件了。

(zt)关于计算机编程的21条“规律”

每个有经验的程序员都知道,在软件开发中存在着一些规律。但是,破坏了这些规律并不会得到惩罚,相反会有些许奖励。
1. 任何一个程序一旦发布就意味着它已经过时了。
2. 让需求根据程序调整往往要比让程序根据需求调整来得容易。
3. 如果一个程序是有用的,那它必将被改变。
4. 如果一个程序是无用的,那它必须被注释。
5. 在任何一个程序里只有10%的代码会被执行。
6. 软件会无限扩张以占用所有的系统资源。
7. 任何有价值的程序都会包含至少一个错误。
8. 一个演示版的程序完美无瑕的几率和关注它的人数成反比,最终要花费的金钱的数量是原数量的平方。
9. 一个程序的致命错误要到其发布至少半年后才会被发现。
10. 不可检测的错误是无穷无尽的,并以各种形式存在;相反,可检测的错误从理论上讲是有限的。
11. 随着时间的推移,修正某个错误所需花费的精力会成指数级增加。
12. 程序的复杂度会一直增长,直到超出维护它的程序员的能力为止。
13. 一段你自己写的代码如果几个月不曾看过,那很有可能其他人也会写出相同的代码。
14. 在每个小程序里都会有一大段代码想要破壳而出。
15. 你越快开始编写代码,就会需要越长的时间。
16. 一个项目如果没有精心策划,那将需要比预期多出两倍的时间来完成它;相反的,如果项目是精心策划过的,就只需要多出一倍的时间。
17. 向一个落后于进度的项目添加程序员只会让项目更加落后于进度。
18. 一个程序的完成程度总在90%到95%之间。
19. 如果你让一团糟糕的代码自动化,那你就会得到一团自动化的糟糕的代码。
20. 建立一个连傻瓜都会使用的程序,而只有一个傻瓜才想要去使用它。
21. 用户直到他们使用了一个程序之后才知道他们究竟想要的是什么。