《 “互联网公司的常见岗位分类” 》 有 5 条评论

1. 互联网公司都有哪些部门，职能是什么？
   https://www.zhihu.com/question/21121826
   `
   成熟的互联网公司如何设立部门，哪些职能最重要，怎样让部门结构适应互联网行业需求？

   作为求职者，要找到合适自己的工作， 就需要了解企业运行的逻辑，而要了解企业的运行逻辑，就要考虑一下企业所在行业的价值链、产业链这些相对宏观的方面，然后再考虑微观的层面。从微观方面，要了解一家企业的运作逻辑，可以去梳理典型企业的核心业务流，岗位都是基于业务流而产生的。

   1.基础活动
   基础活动，就是一个企业得以存在和发展的基本的业务活动，相应的就需要配备支持业务发展的部门，一般在互联网企业中，产品部、技术部、运营部是三个最为基础的部门，这也是一个创业公司必须配置的基本部门，也是一个公司最关键的部门。
   （1）产品部
   （2）技术部
   （3）运营部
   （4）设计部
   （5）市场部
   （6）销售部
   （7）公关部
   （8）客服部
   …

   2.辅助活动
   一个公司的发展，除了需要业务部门为主体来开展基础业务活动，还需要支持部门来支持公司的正常运转，这就需要为业务活动解决人、财、物的部门，主要有行政部、财务部、人力资源部、法务部。
   （1）行政部
   （2）人力资源部
   （3）财务部
   （4）法务部
   …

   ==

   职能岗主要是负责公司整体的业务支撑和人员相关的工作，常见的岗位包含：人力资源（招聘，薪酬，企业文化，培训等），法务，财务，后勤行政，采购类，企业管理。
   `

   回复

2. 互联网公司都有哪些岗位？具体是什么职责？
   https://www.zhihu.com/question/26755083
   `
   # 运营–对公司的产品或服务进行组织、运行、优化等

   * 内容运营–策划产品内容栏目，生产内容
   * 用户运营–负责用户的拉新、促活、留存等
   * 活动运营–负责线上线下活动策划、落地及推广
   * 渠道运营–拓展推广或合作渠道，推进对外合作
   * 产品运营–收集用户需求等相关优化产品的工作

   # 产品经理–收集用户需求绘制原型图输出需求文档

   * 功能型产品经理–负责产品功能迭代，保证用户体验
   * 策略型产品经理–根据公司战略研究产品方向策略
   * 数据型产品经理–依赖数据或数据技术进行相关工作
   * 商业型产品经理–挖掘产品盈利点，落地成产品模块

   # 设计–输出高保真设计稿

   * 交互设计师(UE/UX)–负责界面布局、交互流程及体验
   * 界面视觉设计师(UI)–界面的视觉设计、探索视觉风格
   * 平面视觉设计师–线上线下营销活动、广告海报设计等

   # 前端–将设计稿实现为可交互的动态页面

   * Web前端–负责PC网页或H5页面开发
   * Android研发工程师–负责安卓端产品App开发
   * iOS研发工程师–负责iOS端产品App开发

   # 后端–实现后台服务器系统支持业务逻辑

   * 服务端工程师–负责后台业务系统的开发实现
   * AI算法工程师–基于深度学习对数据分析及预测
   * 大数据工程师–基于大数据技术采集、清洗、加工数据
   * 中间件工程师–服务框架、异步系统等中间层框架的开发
   * 系统架构师–把控系统整体技术架构，攻克技术难点

   # 其他
   * DBA–负责数据库的稳定性、可用性、安全性
   * BI–对原始数据分析和发掘，辅助产品决策
   * 运维工程师–负责服务器可用性和稳定性的维护
   * 测试工程师–对业务系统进行功能测试发现BUG

   ==

   互联网行业的部门通常可以分成6类，分别是产品、运营、市场、技术、设计、职能。
   `

   回复

3. 基础架构部，还有必要吗？
   https://mp.weixin.qq.com/s/yalmoDbY75_Pz9PCzpjiPQ
   `
   过去二十年，中国互联网公司取得了巨大的成就。基础架构部（或者技术平台部，或者运维开发部，或者架构平台部）作为互联网公司的技术底座维护者，贡献巨大。但是随着技术的进步，此类部门的老经验在云时代，越来越不适用，而他们又普遍跟不上新问题。两项加起来，使得大家不得不问一个问题：基础架构部，真的还有价值吗？

   基础架构部的价值是向业务单元交付技术

   基础架构部出于一个目的建立：集中公司的基础设施和架构人才，为业务单元提供技术支撑。

   要达到这个目的，基础架构部需要达到两个条件

   1. 自己要有优秀的技术。
   2. 要能引导业务部门使用优秀的技术。

   很不幸的，在过去若干年来，我们发现基础架构部在两点上得分越来越低。下面我抛砖引玉，指出基础架构部们的一些常见问题，有情各位读者转发，点赞和讨论。

   1. 没有核心技术

   基础架构部年终 PPT 最喜欢强调的就是自己打造了 X，Y，Z平台，为业务单元提供了大数据/运维/可观测性/安全加固能通用能力。

   有些基础架构部的技术大师，还会嘲笑业务单元的开发者是 CRUD 码农，很以自己的技术积累自豪。

   但是打开这些高大上的中台一看，你就会发现，基础架构部的技术大神们其实就是一群开源软件组装老师傅。他们的主要工作就是上 github 找到开源软件X1， X2 和 X3，跑一些莫名其妙的 benchmark，然后选型一个，在自己的机房部署一套。这个过程中，老实人就直接部署社区版本，自己把参数调一调；聪明人就魔改一个，让别人接手不了；更聪明的就仿造一个，让别人根本不想接手。我分别称之为调参师傅，魔改师傅和仿造师傅。

   2. 无法交付业务价值

   过去几年，大数据老师傅玩调参/魔改/仿造这一套最熟练了。最开始大家都用 Hadoop。基础架构部找几个人比较一下 Impala 和 Presto，或者给 Spark streaming 和 Storm 做个测评，就对 CTO 宣称自己掌握了大数据技术，开始建设大数据中台。拿到了预算，闷头干一年，你发现老哥们就做了 web 界面，美其名曰《统一大数据管理平台》。申请到人头多的，还会顺手做一个用户管理平台，结果连个 SSO 都不支持。

   过了几年，当整个 Hadoop 生态被欧美抛弃之后，这些老师傅又开始抓住 Clickhouse 这个救生艇。同样的手法又来一遍。老实人就老实的说“我们部署了若干套Clickhouse”；不老实的就魔改一个Clickhouse，也不管上游兼容不兼容；滑头的就干脆对着 Clickhouse 仿一个。

   全国起码有上百个基础架构部（或者大数据平台部，或者数据中台）过去十年就干这些事。这些老师傅凑在一起，就是比拼“你要用六百台机器啊，我只要三百台”，或者“我消化5T数据只要一个小时，比你的70分钟快了14%”。从业务单元的视角来看，其状非常幼稚，类似两个初中男生在比拼“你只能尿两米，我能尿三米”。

   实际上，业务单元在乎的不是你用了几台机器。他们关心的是你的大数据平台能不能产生业务价值。

   * 你的大数据平台能否自主接入新数据源？
   * 你的大数据平台能不能和 BI 工具方便的对接？
   * 你的大数据平台有没有精细的访问控制和访问审计？
   * 你的大数据平台能不能精确的给业务单元计费？
   * 你的大数据平台怎样帮助业务部门做到个人信息保护合规？

   但是由于基础架构部的运维文化，他们几乎不会考虑这些高层次的问题，每天就在自己的舒适区，从机器上抠性能。有时候甚至会发一些很奇怪的喜报，比如“经过三个工程师半年的努力之后，我们给公司节省了半台机器，合计五万块钱”。

   现在，业界大数据发展到下一阶段，以 Snowflake/BigQuery/Athena为代表的大数据平台，特别强调易用性，从全流程上降低数据的使用门槛，尽量把更多的公司员工发展为大数据用户，最大化的把数据变现。但是他们都是云服务，而不是开源软件，你就看到老师傅们根本玩不转了。

   3. 技术理念落后

   过去十几年，软件工程行业缓慢但是坚定的发生了一系列技术革新，使得软件行业和十五年前的差别非常大了。但是没有一个单一的进步像 iPhone 或者 ChatGPT 那样具备戏剧性效果，因此很多从业者没有感受到这种进步，这其中，就有很多架构平台部的决策者和工程师。在理念的落后，导致一系列的技术落后，他们已经失去了和业务单元的技术势差，甚至出现了倒势差。

   4. 沉迷于已经解决的 Scalability 问题

   基础架构部们技术大师们最喜欢谈的就是高并发问题。阿里的出门就谈双十一有多少笔交易，腾讯的上台就甩一个QQ的十亿用户数，百度的开口就提中国用户一天搜索多少次，往往把初学者们吓得一愣一愣的。

   实事求是的说，二十年业界普遍使用 LAMP 架构，很多团队被 C10K 问题困扰，那时候 BAT 们摸索出一些海量服务工程实践，是有价值的，毕竟支撑了公司的业务增长。

   但是二十年过去了，可扩展性（Scalability）是一个已经被解决的问题。基本做法大同小异：

   1. 使用微服务，各个服务拥有独立的资源
   2. 确保 web server 都保持 stateless，以使其自动 scale out/in。
   2.1. 使用负载均衡承接外部请求。
   2.2. 使用容器分发，拒绝手工部署二进制；
   2.3. 不使用难以扩展的文件系统，而使用和计算节点脱偶的对象存储；
   2.4. 确保每个 pod 都是可以替换的；
   3. 使用支持自动扩容的分布式数据库，必要的时候加缓存。
   4. 使用消息队列缝合不同系统的处理能力差别。
   5. 使用 Infra as Code 确保上述系统 immutable，并且可以复制。
   6. 建立一个包含代码，配置，secrets的 CI/CD 流程，确保代码质量。
   7. 为每个微服务提供 out of box 的可观测性 dashboard。
   8. 如果有必要，在业务层面对用户做 partition。

   基本上，这个最佳实践能够覆盖绝大多数负载。并且，每一步都有工具可以支撑，任何一个工程师都可以在自己的团队落地。

   作为对比，基础架构部大师们讲高并发的时候，要么在线程/进程的细节上喋喋不休，要么就念叨一些“双活”之类半通不通的话，你问多几句，对方就会生气的反问：“你处理过双十一吗？你知道我管多少机器吗？你用户有十亿吗？”，说句难听的，基本就是神棍们在跳大神。

   5. 死抱着 ClickOps

   总所周知，中国软件工程师长期处于过劳状态，以至于从业者过劳死新闻都没有热度了。其中一个重要原因，就是行业自动化非常不普遍。

   这个现象非常具备讽刺性。工程师们的工作就是开发软件，通过互联网为用户自动化一些年底报税，入学申请，核酸检测等工作，但是工程师自己拒绝自动化，大量的工作依靠肩挑背扛。

   6. 阻碍 DevOps

   除了技术落后，有时候基础架构还会出于团队利益，故意为团队效率设置障碍。比如有的部门会打着各种旗号，一手掌控所有基础资源。开发者需要一个对象文件桶？打报告申请！开发者需要一个数据库？打报告申请！开发者更新一句 SQL？排队等 DBA 老师傅审批！开发者查看系统状态？不给权限！

   基础架构部主导的持续集成持续部署（CI/CD）流水线，往往只有持续集成 CI 部分，故意切断CD部分，美其名曰“保障现网稳定性”。实际上他们就是担心开放持续部署系统之后，业务单元的开发团队发现没有中间人效率更高质量更可靠，他们部门就无事可做了。

   7. 猜疑专业软件供应商

   尽管都是同一公司的部门，但是在关系上，基础架构部和业务单元其实是甲方和供应商的关系。非常自然的，供应商会天然的排斥其他供应商。尽管外部有优秀的可观测性供应商，基础架构部就是不用，要自己搭建难用的 ELK。尽管外部有可靠的 RDS，基础架构部就是要自己搭建 MySQL。

   在飞书和钉钉流行之前，中国五百强里起码有两百个企业养了一个团队在研发内部 IM 工具。大量的人力浪费在造劣质轮子上。这些所谓更适应企业特殊需求的 IM，不仅难用，而且很不安全，往往用着用着，整个团队就提桶跑路了。多说一句，游戏公司研发自己的 HR 系统，外卖公司研发自己的代码管理工具，电信设备企业研发自己的差旅管理系统，都是吃得太饱了，拿着雇主的钱给自己招兵买马占地盘。

   8. 和业务单元的关系扭曲

   很多基础架构部主张自己的价值是：“老板，我是自己人，更懂业务需求！”听上去似乎很有道理。

   实际上，大多数互联网公司的技术并非核心竞争力，只需要通用软件技术，并没有那么多独特的需求。恰恰相反的是，如果业务单元有很多独特的，业界普遍不支持的软件需求，很可能说明他们的软件选型出了问题。

   9. 守旧的心态

   大多数公司的基础架构部，都脱胎于运维团队，非常强调可靠性（reliability）。一方面这是优势，但是另外一方面形成了一种守旧文化。运维老师傅的口头禅是“如果能工作就不要动它”

   如果你打开很多先进公司的技术栈，会发现成堆的 MySQL 5.7，CentOS，Python 2.X，GCC 4.9，这些基础软件都已经不再维护了，即使有安全漏洞也不再有补丁，因此不管兼容性还是安全性都非常不可靠。本来应该对这些过期软件负责的基础架构部，由于肩负着可用性指标，往往是最反对升级技术的部门。
   `

   回复

4. 驳马工《基础架构部还有必要吗？》
   https://mp.weixin.qq.com/s/0W676wBcGjP5XeqBYoBYeQ
   `
   1. 基础架构部的价值是什么？

   正如马工文中所说，基础架构部是为了向业务单位交付技术，并且要具备两个前提：
   1. 自己有优秀的技术
   2. 要能引导业务部门使用优秀的技术

   1.1 技术的“优秀”与否要看场景

   但是，“优秀”不是有唯一标准的，什么算优秀的技术？技术都是有 tradeoff 的，比如某一种技术能获取最高的性能，但是它对于很多公司来说并没有意义，因为它的功能太简单，成本太高。
   而每个业务场景下的优秀的标准就是不同的，公司和公司之间并不是在同一个领域进行竞争，所以服务于公司业务的基础架构部当然也不应该有统一的目标，比如追求最高并发服务能力。
   比如 SaaS 世界第一股 Salesforce 长期以来用的技术都是互联网喊着去 IOE 里的 Oracle 作为底层存储，上面的并发数也很低，你能说 Salesforce 的技术不优秀么？只能说在它的领域里它的技术很不错，但是不符合你的领域的要求。你一个猫为什么要和企鹅比赛跑步呢？人家企鹅是游泳游的好啊。

   1.2 “引导”业务部门？

   基础架构部大概率作为一个横向部门存在，它减少部门间的重复建设或者错误建设。实际上过去互联网时代和移动互联网时代，互联网公司都以增长为核心指标，过程里会大量引入没有那么合格的程序员来快速试错新的业务领域。如果没有一个横向部门去进行“引导”和“规约”，业务确实有可能过于“野蛮”生长。

   2. 基础架构部有没有核心技术？

   2.1 真的是“调参”，“魔改”，“仿造“师傅么？

   马工的文章讨论了基础架构部有没有核心技术，里面把工程师分成了“调参”师傅，“魔改”师傅，和”仿造”师傅。
   这点我是完全同意的，但是so what？中国互联网公司几乎都有美国对标，和美国同行几乎从事完全一样的业务，那么用和美国同行几乎一样的技术也就无可厚非了，这可能就是确定性最高，风险性最小的技术选型了，C2C 本来的意思就是摸着美国过河，商业模式可以 Copy，技术栈有什么问题？
   而且，美国硅谷公司的非业务公司，比如 twitter （现在的 X），facebook （现在的Meta），airbnb 等巨头基本都是基于开源技术起家的，然后在发展的过程里遇到问题解决问题，这个过程就是”调参“和”魔改“。不过，“仿造”其实是大公司病的体现

   2.2 “仿造”是大公司病

   当公司大了，公司对个人晋升和嘉奖的“维度”就开始变了，从贡献变成了贡献✖️难度，但是公司大了，业务稳定了，大部分贡献就变成了统一的“微不足道”，就开始有打工人为了获得更好的绩效和晋升机会，开始通过强行提高难度来刷个人存在感。
   “仿造“ 这种病来源于公司大了后每个团队的目标和公司整体目标脱节，不管公司用 KPI 还是 OKR 都不能阻挡它的出现。现实里，”仿造”一般会找一个较好的立项原因，总能找到一些可以通过“仿造”解决的点。是仿造还是超越，存乎一心，但是如果完全不存在这种灰度，可能创新也无从谈起，因为很多东西在你仿造一遍之前，你都掌握不了它的关键所在。魔鬼在细节里，不动手亲力亲为，你永远不知道谁是无足轻重的细节，而谁是魔鬼。
   总而言之，大公司病不见得是坏事，可能也是大公司的资源和利润给了创新一定的宽松的空间，但是投资不一定有回报，不投资一定没有回报。

   2.3 改开源软件怎么了？

   我们知道开源软件一般来自几种开发者：
   1. 大公司为了自己的商业目的开源的，为了抢占市场打击竞争对手，不靠软件赚钱（Android、chrome、kubernetes，vscode 都是此类）
   2. 商业化公司经营的开源软件，通过开源转化付费客户（ElasticSearch，Nginx，MySql，Cassandra）
   3. 有开源基金会开源的软件（来自 GNU 的软件，linux）
   一般来说，1 会按照自己的 roadmap 前进，不会太在乎冷门的需求；2 会故意弱化企业级功能（要不是商业版怎么收费？）；3 的话，一般都是 welcome to your PR，而不是商业软件的服务感。
   全球的互联网公司一般都鼓励员工修改（魔改）开源软件，但是 Facebook 能把 HBASE 的主导权拿到公司内来主导，Google 可以对 Linux 上游提交 cgroup 的 patch。可见**魔改开源不是原罪，“菜”才是原罪**。

   3. 基础架构部是如何交付业务价值的？

   基础架构部一般以一个横向部门的角色出现，并没有自己可以计算 ROI 的业务收入，但是基础架构部实际是通过一些更通用的指标来体现价值的，比如可用性，伸缩性，以及业务迭代速度。能抓到老鼠就是好猫，即使这个猫没有涂最先进的指甲油。在互联网公司里技术是服务于业务的，而大部分公司不是 FAANG。要求一个普通公司的保安发明出星球大战的装备这不公平也不现实。

   4. 技术理念落后

   落后与否是相对的，Apple 在服务端技术上也没有啥创新，也是 Copy from Google Or 其他公司，那么 Apple 是否是一个落后的公司呢？每个公司都有自己擅长的领域，在自己的细分领域里（比如送餐/卖票/电商/营销）技术不落后就可以了。相反，每个公司都卷 Proxy 或者 K8S 的部署情况。才不利于整个技术大环境的整体发展和氛围

   4.1 为什么我们会执迷于 scalability？

   因为基础架构部负责的工作就是可用性，伸缩性。说别的显得不务正业了。

   5. 基础架构部已经变成阻碍技术进步的恶龙了么？

   对于任何团队来说，在组织里体现自己的价值都是必不可少的工作，横向部门殊为不易，往往只有背锅的时候才能体现。所以整个研发体系的底座趋向于保守，很正常，因为这符合它的定位和存在的意义。基础架构团队往往要规约业务团队的需求和行为，所以显得颇有出力不讨好之嫌。但是这也是公司内不可缺少的制衡之力。

   5.1 组织惯性

   而且这是历史上所有的组织的惯性，几乎没有组织会从内部进步和革新，都是要靠外力驱动的。比如苏联红军在遭遇德军的坦克前还是对哥萨克骑兵寄予厚望。基础架构团队和任何团队没有区别，它的使命是托举住公司的业务，如果他完成了这个使命，大概率不会有自我革新的动力。但是这也不是哥萨克骑兵的错。

   5.2 非技术公司的竞争壁垒并非技术

   **我国市场上大部分的互联网公司并不是技术驱动，所以也不需要一个不断进化的基础架构部。相反在业务没有实现高速增长的前提下，控制成本才更现实。**

   5.3 基础架构部为什么会排斥外部技术提供商呢？

   基础架构部很多时候就是内部技术提供商，排斥外部竞争对手符合人性。毕竟大部分外部供应商采取的方式和基础架构部几乎一样（本来就是同行），也是基于开源系统都魔改和调参，甚至临摹。你让基础架构部怎么放下手里的枪，去采购别人的枪呢？甲方乙方都有各自的问题。

   6. Fade Away

   Old soldiers never die，simply fade away。

   新的生产力一定会催生新的生产关系。
   基础架构团队本身是上一个时代的互联网公司的缩影：愿意用超配的资源去实现增长。但是任何时代都有落幕的时候，基础架构部也会如其他高增长所超配的资源一样被减配。互联网公司都会从高投入转向高 ROI 导向的理性投入。从一定要自主可控转向用更合理的成本去实现可控。
   基础架构团队会走向如下几个方向：
   1. 拥抱云，降低人员成本。
   2. 拥抱市场，提供产品到市场上参与竞争。
   从 ROI 的角度重新对基础架构这个角色估值和定位，会把滥竽充数的东郭先生们从队伍里拖出去。时代的产物当然会跟随时代的步伐去发展。
   `

   回复

5. 甲方安全和乙方安全的区别
   https://mp.weixin.qq.com/s/ISnvINpvitiQ7KHnSkeplQ
   `
   信息安全工作，总会被人分成甲方和乙方，甲乙方原本只是商务层面需方和供方的代称，在安全领域，成了做公司内部安全和为客户提供安全的区别。

   通常意义上，什么是甲方安全人员呢？就是在非安全业务的公司从事信息安全工作的人。什么是乙方安全人员呢？就是在主业是安全业务的公司从事信息安全工作的人。由于多年以来的刻板印象，似乎技术人员都不大倾向在乙方工作，对于乙方安全工作的印象是：
   工作贼多、收入贼少、福利稀少、管理混乱、产研紊乱。

   而对甲方安全工作的印象则是：
   工作不多、收入特多、福利多多、管理规范、产研标准。

   既然是刻板印象，说明其印象是不准确的。首先要搞清楚的是，到底什么是甲方，什么是乙方。根据业务的商业模式划分的话，甲乙方关系中的角色能够分为四类：政府机关、个人用户、2B业务和2C业务，其中2B业务是to business的业务，或面向客户的业务，如广告公司给客户做广告、SaaS公司给客户卖帐号，2C业务是to customer的业务，或面向用户的业务，如饭店给用户卖小龙虾、电商平台给用户卖商品。这四种角色的组合不算在内，诸如C2C（比如某乎）、B2B2C（比如某宝）。同一家公司也会经营不同商业模式的业务，既经营2C业务，也经营2B业务，比如多数银行既做个人业务，也做企业业务，而中国人民银行则只做企业业务，不做个人业务。

   所以，当我们说甲方安全和乙方安全的时候，实际上是说安全工作是否是业务工作，比如某个不足百人的，主营业务是2B业务的公司，招聘的安全人员，也是甲方安全人员。而由如绿盟、启明星辰这类传统的老牌上市安全公司，因为安全工作就是业务内容，即便公司规模大，业务多，其招聘的安全人员，也是乙方安全人员。

   所以，觉得甲方安全工作量不如乙方，原因包括，所谓的甲方安全工作对公司和业务而言不是第一位的，在技术人员偏向甲方的情况下，乙方安全人员能力和人数不占优势。

   所以，即便是甲方安全工作，也会因为公司所在的行业和商业模式不同，盈利能力不同，而薪酬待遇只是公司营收能力的间接体现。

   所以，收入和福利，取决于公司现金流以及人力建设成熟度，而非甲乙方。一个人的能力体现，薪酬是一方面，另一方面是人力成本占比。

   所以，管理和产研是否规范，与甲方或乙方无关，可遇不可求。

   安全工作的涵盖内容多，方向多，在甲方做安全建设，需要解决不同维度和层面的安全问题，因此安全工作的方向涵盖方方面面，比如：外部有物理安全、主机安全、网络安全、应用安全、数据安全、业务安全，内部有人员安全、身份安全、终端安全、内网安全、物理安全，每一个方面在安全建设逐渐完善过程中都会遇到，但又无法每一方面都自研，因此需要向乙方安全公司采购。而乙方安全公司，由于业务指向和专业性，无法兼顾所有的安全方向，比如做应用安全，会更专注黑盒、白盒、灰盒等安全检测能力。

   甲方的安全建设，需要基于已有的资源和预算着手，而任何一种信息技术都存在安全风险，也就有相应的安全技术方向，但服务范围和资源限制，导致甲方安全工作不大可能脱离现有的业务范围进行其他方面的技术发展和研究，比如业务形态只有App的公司，其安全工作几乎无法涉猎IoT安全、工控安全等领域，安全技术工作需要跟随业务的发展和需要，但同时也局限在业务形态之内。乙方安全公司，则因为会面临各种不同的客户、业务和安全需求，其安全技术的涉猎和拓展无论多宽泛，都可以是为下一个客户做准备，另外，从客户的角度，由于对信息安全的刻板印象，不全面的安全知识体系会让客户认为对方不够专业，就像隔壁阿婆会认为程序员应当会修电脑，如果修不了，可能会觉得做程序员不合格。
   …

   如此，是否一定要执着于甲方或乙方呢？**只要入水游若蛟龙，又哪管是河是江是大海**（当然，如果你这条蛟龙实在是太大，确实需要去更大的平台来承载你的能力和野心）。
   `

   回复