Brain Dumps

我们多年帮助客户申请PERM劳工证申请的过程中，发现很多客户包括大公司的人力资源 经理对于PERM劳工证申请有很多误解。带着这些误解提交的劳工证申请自然容易被劳工 部挑出毛病，要求审计，甚至是监督招聘的全过程。于是很多人对于劳工证谈虎色变。 其实劳工证的申请没有那么可怕，有经验的律师会对全过程有精心的策划和掌控。不仅 仅是在PERM 阶段确保批复，而且对于I-140 和I-485 过程中可能碰到的问题都有前瞻 的准备。。在此我们给大家做一个PERM劳工证误解释疑。希望能够给以PERM劳工证的方 式申请绿卡的申请人提供更清楚的指导。下文所指的PERM劳工证申请人系雇主；申请受 益人系外国雇员。 • PERM劳工证的申请是以H-1B为先决条件的； 错误。 尽管很多受益人都是在劳工证申请人处工作一段时间后开始劳工证的申请的，但因为 PERM劳工证的申请不是针对申请受益人现在的工作职位，而是针对受益人在取得绿卡之 后的职位，受益人是否持有申请人支持的H-1B签证和劳工证的申请没有关系，更不是劳 工证申请的先决条件。受益人的劳工证可以在任何时间开始准备，不用等到H-1B 开始 后才开始。 案例：Suhas 是在印度工作的软件工程师，美国一家公司对他的背景很感兴趣。但是由 于双方接触的时间太晚，美国雇主尚未来得及递交H-1B申请，H-1B的名额就告罄，只能 等到下一年。在等待递交H-1B的同时，雇主希望能够开始绿卡申请。由于H-1B并非劳工 证的先决条件，该雇主在任何时间可以开始为Suhas 申请绿卡。 • PERM劳工证的申请必须有受益人现任的雇主来支持； 错误。 尽管大部分的劳工证申请都是由现任雇主支持的，但是现任雇主支持并非劳工证申请的 法律要求。受益人可以为A 雇主工作，但由B雇主来支持劳工证的申请。上面提到，劳 工证是针对受益人将来的职位的，所以受益人是否在劳工证申请人处工作不对劳工证的 申请产生任何影响。 案例：金先生供职于一家大型会计事务所，由于金融危机，事务所停止办理任何绿卡申 请。眼看金先生的H-1B 6年到期，绿卡尚未提到日程。金先生准备忍痛从大公司转到一 家愿意支持绿卡的小公司工作。经咨询冯律师，他知道既可以保留现在大公司的职位， 又可以同时让小公司支持绿卡。小公司非常愿意为金先生办理绿卡申请

最近疫苗问题又火了，而我正好在几个月前写过一篇关于脊髓灰质炎（简称Polio）的文章。下面我以Polio疫苗为例，简单介绍一下大部分疫苗都是怎么一回事，以及疫苗的本质究竟是什么。 Polio是病毒，通过粪便传染，经由饮食进入健康人的消化道。防病毒不能靠抗生素，只能靠人体免疫系统来对付。疫苗的作用就是特异性地刺激免疫系统，使之“记住”Polio病毒的样子，一旦真的遇到Polio病毒入侵，免疫系统就会在第一时间迅速对它发起攻击，将其消灭在摇篮里。 为了达到这个目的，有两种不同的策略：第一是用毒性减弱、但蛋白质外壳基本相同的所谓“减活Polio病毒”去刺激免疫系统，这就相当于让人真的感染一次，只不过症状很轻，不会残疾。这个策略用的是活病毒，所以对免疫系统的刺激相对较强，理论上只需接种一次就行了。另外Polio本来就是通过消化道入侵人体的，所以这类疫苗可以被做成糖丸或者滴液，便于小孩服用，操作起来难度较低，绝大部分发展中国家使用的都是这种疫苗，对于在全球范围内消灭Polio起到了决定性的作用。 第二是用“灭活Polio病毒”，即真正有毒的Polio病毒的尸体来刺激免疫系统。因为用的是死病毒，所以必须肌肉注射，而且往往需要注射好几次才能对免疫系统产生足够强的刺激，操作起来难度要大得多。   目前绝大部分疫苗采用的都是上述两种策略之一，几无例外。 各位读者可以根据这两个策略的特点，自行判断你打的疫苗究竟属于哪一类，应该注意些什么。 第一种策略使用的减活病毒有可能在自然环境里发生基因变异，变成有毒的Polio病毒，所以存在一定的风险。据统计，2000年以后全世界一共发生了20次因为减活Polio疫苗基因变异而导致的疫情，加起来一共有580名儿童因此而生病。 第二种策略使用的灭活病毒有可能因为灭活不彻底而让接种者患病，事实上美国在进行第一次疫苗大规模人体试验时就曾经发生过这样的事情，这就相当于给健康的孩子直接注射Polio病毒，结果可想而知。虽然现在疫苗制造工艺更加完善了，这类事情已经很难再发生，但毕竟要采取肌肉注射，对产品质量和运输冷链的要求非常高，难免还会出现疫苗质量不过关，起不到免疫效果的情况。 说了半天，我的意思就是：疫苗接种一直是存在风险的，即使是西方发达国家也无法完全避免。 我们之所以称疫苗是个好东西，

看到很多文章都提到美国在1955年的疫苗危机后加强了对疫苗生产和运输的管理，于是我搜了搜英文资料，想多知道点这方面的情况。 结果……却意外地了解到了当年美国人投入举国之力研制小儿麻痹症疫苗、最后成功战胜绝症的那段精彩历史。 不如讲讲这个鼓舞人心的故事吧，希望它能稍稍地驱散弥漫在你心头的那种无力感。 1、 小儿麻痹症，也叫脊髓灰质炎，英文是Polio。大多数人对这种病的唯一记忆，大概就是小时候吃糖豆和打预防针。 我们现在很少提这种病，是因为它在全球范围内已经基本上被根除了，目前只在阿富汗、巴基斯坦和尼日利亚这三个国家还有传播。 1988年全世界的小儿麻痹症病例高达35万起，但到了2017年这个数字下降到了区区22起。 按照世界卫生组织官网上的说法，人类根除小儿麻痹症的目标已经完成了99%——而这一切，都是拜疫苗所赐。 小儿麻痹症是一种急性传染病，病毒经血液入侵神经中枢，轻则造成肌肉萎缩，重则夺去病人的生命。虽然任何年龄都可能感染，但主要的发病人群是5岁以下的儿童。 上世纪初开始，美国很多城市先后爆发小儿麻痹症疫情。 最严重的1952年，全美国一共有57000人感染，街上因为患病而造成腿部肌肉萎缩行走不便的儿童随处可见。 他们就像是刚刚从战场上打仗回来的伤兵，只不过这些伤兵都是孩子。 如果病毒影响到呼吸肌，肺功能受到影响，那就更危险了。所以当时医院用这种称为“铁肺”的装置来帮助病人进行呼吸。 小儿麻痹症疫情一般在夏季集中爆发，5月开始，到8月到达顶峰，一直持续到9月初才结束，然后到第二年再重新开始，就像蝗虫一样每年都来一次。 这是让父母们胆战心惊的死亡夏季，他们因此不敢让送孩子们去夏令营、开生日会，甚至不愿意让孩子们去上学，海滩和公共泳池在夏天反而变得空空荡荡。 人们不清楚病毒的传播途径，对于生病的原因有各种各样奇怪的猜测，猫狗、跳猴子、甚至南美进口的香蕉都成了被怀疑的对象。 父母们不知道什么时候自己的孩子就会中招感染，看起来就像是病魔在实施无差别随机杀人计划，这种未知无疑也放大了恐惧感。 因此，虽然小儿麻痹症的致死率和其他病比起来并不算高，但当时它却是美国人最害怕的疾病，像是幽灵一样年复一年地盘旋在美国社会

从目前可以得到的信息来看，对分布式服务化架构实践最早的应该是亚马逊。因为早在 2002 年的时候，亚马逊 CEO 杰夫·贝索斯（Jeff Bezos）就向全公司颁布了下面的这几条架构规定（来自《Steve Yegge 对 Google 平台吐槽》一文）。 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。 团队间程序模块的信息通信，都要通过这些接口。 除此之外没有其它的通信方式。其他形式一概不允许：不能直接链结别的程序（把其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。 不这样做的人会被炒鱿鱼。 这应该就是 AWS（Amazon Web Service）出现的基因吧。当然，前面说过，采用分布式系统架构后会出现很多的问题。比如： 一个线上故障的工单会在不同的服务和不同的团队中转过来转过去的。 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都要做好配额和限流。 监控和查错变得更为复杂。除非有非常强大的监控手段。 服务发现和服务治理也变得非常复杂。 为了克服这些问题，亚马逊这么多年的实践让其可以运维和管理极其复杂的分布式服务架构。我觉得主要有以下几点。 分布式服务的架构需要分布式的团队架构。在亚马逊，一个服务由一个小团队（Two Pizza Team 不超过 16 个人，两张 Pizza 可以喂饱的团队）负责，从前端负责到数据，从需求分析负责到上线运维。这是良性的分工策略——按职责分工，而不是按技能分工。 分布式服务查错不容易。一旦出现比较严重的故障，需要整体查错。出现一个 S2 的故障，就可以看到每个团队的人都会上线。在工单系统里能看到，在故障发生的一开始，大家都在签到并自查自己的系统。如果没问题，也要在线待命（standby）

过一次年，结婚、存款、父母养老，一系列向钱看的事都在碾压我们本来还挺简单的神经，但难过没有出路，唯有找到好的方法和事业方向，才能实现一步一个脚印的逆袭。 下面是一名资深Linux运维求职数十家公司总结的Linux运维面试精华，助力大家年后跳槽找个高薪好工作。 1、什么是运维？什么是游戏运维？ 1）运维是指大型组织已经建立好的网络软硬件的维护，就是要保证业务的上线与运作的正常， 在他运转的过程中，对他进行维护，他集合了网络、系统、数据库、开发、安全、监控于一身的技术 运维又包括很多种，有DBA运维、网站运维、虚拟化运维、监控运维、游戏运维等等 2）游戏运维又有分工，分为开发运维、应用运维（业务运维）和系统运维 开发运维：是给应用运维开发运维工具和运维平台的 应用运维：是给业务上线、维护和做故障排除的，用开发运维开发出来的工具给业务上线、维护、做故障排查 系统运维：是给应用运维提供业务上的基础设施，比如：系统、网络、监控、硬件等等 总结：开发运维和系统运维给应用运维提供了“工具”和“基础设施”上的支撑 开发运维、应用运维和系统运维他们的工作是环环相扣的 2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的？ 游戏运营要做的一个事情除了协调工作以外 还需要与各平台沟通，做好开服的时间、开服数、用户导量、活动等计划 3、现在给你三百台服务器，你怎么对他们进行管理？ 管理3百台服务器的方式： 1）设定跳板机，使用统一账号登录，便于安全与登录的考量。 2）使用salt、ansiable、puppet进行系统的统一调度与配置的统一管理。 3）建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。  4、简述raid0 raid1 raid5 三种工作模式的工作原理及特点 RAID，可以把硬盘整合成一个大磁盘，还可以在大磁盘上再分区，放数据 还有一个大功能，多块盘放在一起可以有冗余（备份） RAID整合方式有很多，常用的：0 1 5 10 RAID 0，可以是一块盘和N个盘组合  其优点读写快，是RAID中最好的 缺点：没有冗余，一块坏了数据就全没有了 RAID 1，只能2块盘，盘的大小可以不一样，以小的为准 10G+10G只有10G，另一个做备份。它有100%的冗余，缺点：浪费资源，成本高