网站技术职位之我见：报错

文章出处：http://blog.helosa.org/2010/07/16/website-job.html 搭建一个网站，需要很多职能的人加在一起，如策划、美工、技术等。小时候，这么多的职能，就是一个人去完成。自己把网站构图画出来，自己 写html 代码，写动态程序，发布上传。当在地址栏输入网址，看到自己的作品时，那是很兴奋的一件事。出来工作后，这些职能终于分开了，有专门的产品策划，还有 SEO 专员，有美术和前端页面工程师，还有一个我觉得名字有点怪的后端工程师，哈哈。一个网站是一个团队的结晶，再也不是一个人独立去完成的了，一个人最多作为 一个团队的核心成员。儿时那种喜悦感荡漾无存。 我是做技术的，表达下我对一个网站技术类职位的一点点看法。 ——————————– 前端工程师，主要负责面向用户的页面代码编写。熟悉html 和 javascript 是最基本的。想当年，我还不会利用工具，还试过全手工写html 代码呢，当然，现在很多geek 都是直接 vim 或 emacs 编写简单的网页的。想方便快捷地写html 代码呢，还是得利用工具的，人和动物最大的不同嘛，就是懂不懂利用工具了。那些什么 frontpage 啦，dreamweaver 啦，都是工具，我小时候还用过一个好像叫东方网页魔术师的东西呢，内置了很多当时以为很有型的javascript 效果（别笑！）。前端工程师的源代码没有闭源一说，因为所有的代码都是运行在用户的浏览器上面的。前几年ajax 开始大行其道，于是javascript 开始重新热起来，不过这次不是因为js 的那种所谓的效果了。其实ajax 就是利用javascript 异步对服务器发出请求，服务器返回后，重新渲染页面，这就是局部刷新。 在这个职位上做得最为出色，个人觉得，就是灵活地运用javascript 造成各种有创意的效果。前端工程师的代码就是直接面向用户的阿，把用户的体验提高到顶点，就像用户在操作自己的电脑一样。gmail 简直就是这方面的极致！有些geek 还利用html 标签弄出一幅画出来，甚至还动画，我只能说，牛人阿！ 最怕的是，在这个职位上流于完成日复一日的任务。大公司里，会有美工把页面需要展示的效果做成一个图片，然后前端工程师就把这个图片用html 代码写出来，俗称：切页面。千万不能每天都重复着没有意义的切页面工作。这个职位应该是一个很有创意的职位，而不是一个只会切页面的工人。 其实前端工程师，我觉得，还可以包括flash 的程序员的。由最初的flash 动画，到近几年很热的 flex ，flex 是当前很热的web game 的主力呢。至于flex ，涉及很多对后端的操作，划入前端工程师的范围貌似不太对。但是作为一个技术人员，就应该所有部分都掌握了解才可以把一个产品做出来。 随着时间的推移，html5 的出炉，将会令到前端工程师的地位上升到一个高度。html5 自带了绘图的标签，甚至可能可以替代flash 的绝对地位呢。 ——————————- 后端工程师，好像也统称为开发工程师吧。简单地说，就是那些java, php, python 程序员吧。由于js 是运行与客户端的程序，它并不能访问数据库，这个对数据库的操作，就交给动态语言去处理了。例如，用户访问一个 update.php ，最终可能只会得到一个 html 的返回，但其实，这个程序已经对数据库进行了读写操作，这个html 返回，并不是每个用户都是一致的，所以就叫做动态语言。每个访问 update.php 的人，都可能得到不同的返回。 开发工程师，最怕流于平时只会利用各种组件，调用各种api 去实现某些东西。如果不主动思考去改进，去深入，那么平时的工作，就像是堆积木，互联网民工就是这样产生的。最近听朋友在面试时，就说遇到很多人，说是拥 有几年的工作经验，把自己工作领域的内容，滚瓜烂熟的样子，但是知识面很窄，甚至可能连缓存是什么都不知道，一直开发桌面软件不去注意性能？互联网，相关 知识日新月异，今年流行的技术，可能明年就落后了。就正如前几天流行的一句话，“你以为你有10 年的工作经验吗？？其实你只是1 年的工作经验，复制10 次而已”。在一个web 开发框架下，熟练地运用相应的类、函数，处理的是程序逻辑，也就是处理下 if a = 1 , then do sth 这样的简单逻辑，然后不断地重复，再重复，这些最终都只是流于设计出展现给用户的那部分界面，其实毫无技术含量可言的。以前小时候看着，以为程序员很 cool ，后来才知道，其实，不是所有的程序员都很cool 的。。。 毕竟我不是这个范畴的专家，甚至我也只是多年前涉足了一下这个领域，但我觉得，如果开发工程师，可以在现有的开发框架下，设计出符合自己的业务需求的框架，或一个很完善的开放平台，就很完满了。就像豆瓣那些大牛们。 至于不同的语言，我觉得从我的角度来看，没有本质的区别。都是处理动态请求的程序，我的角度，统称为 app 。 我自己以前小时候还是做过开发的，那时候还不会用框架，直接jsp 就上了，什么html 页面代码都在jsp 里面，乱死了。那次是一个期末作业，连续一个星期一天16 小时地写jsp 代码，不分日夜地调试阿，google 阿，终于把作业完成，还得到老师的好评。不过我看回来还是觉得挺有趣的，毕竟以前做作业的心情不再，现在再也没静下心来开发一个功能完备的网站了。 今天刚看到一句话，java 工程师，是最远离计算机科学的，因为所有对象都封装，这个封装那个，最上层的，只是把对象的方法调用一下，就完成了一系列的任务。远离了计算机的底层，根 本不知道计算机真正在做什么。这种情况下，可能对性能的优化，产生不良的影响了。而我觉得呢，java 工程师，更应该向软件架构师的方向去走，因为java 的思想就包含了许多软件工程的思想，理解了java 的人可以很容易地从宏观去设计一个产品。至于细节的考虑，就相对较少了。 —————————— DBA ，database administrator，数据库管理员吧，这个翻译真别扭，我还是喜欢直接用英文。就是管数据的那班人。 一句话就可以概括DBA 的重要性了，“代码可以重写，但数据不能再造”。本人很肤浅地认为，DBA 作为一间公司的雇员，占据着核心的地位。在这里，有可能会问，那程序员和DBA 相比，谁更核心呢？我资历是很浅的，不负责地讲一句，DBA 才是核心。设想下，如果一个系统拥有3 年的数据了，数据量达到数T ，那么，这个时候，如果失去程序和失去数据两个选择，相信大部分人都会选择失去程序，因为程序仍然可以根据其业务逻辑重写出来，但是生产环境的数据无法伪 造出来。 web 2.0 中，这个核心作用表现得更甚。web 2.0 中，通常业务逻辑并不复杂，对数据库的逻辑往往也并不复杂，不会有很多join 表的操作，但高并发对于数据库的压力是web 1.0 时代的n 倍，往往一个web 2.0 的系统的瓶颈就在DB 这里了。 我这个SA 嘛，以前还是有挺多机会弄弄数据库相关的工作的，经常可以客串一下DBA 。当初老大也是想把我培养成为DBA 的，可惜我不争气。。。我客串DBA 的时候，对一些接近满载的机器，进行参数调优，负载下降到1 以下。那时候心里很爽的样子，到处找实战机会，哈哈。不过，毕竟是客串，我对DB 的很多方面，都没有深入认知。。。 DBA 需要掌握的技能，就相对更多了，同时对个方面的关注度也十分高。磁盘的io ，吞吐率，网络知识，开发编程知识，操作系统的内核参数，计算机硬件知识，甚至于内核的新 feature ，每方面都可能对DB 的性能造成影响。 DBA 发展下去，这么全面的知识积累，往往可能成为系统架构师。 ——————————- SA，system adminstrator，系统管理员，终于说到我的职位了！非要加个工程师的头衔的话，可以叫做系统工程师，或者运维工程师。 SA ，貌似没有具体要掌握哪些技能，也可以说，是什么都得掌握一些，什么都得懂。离谱一点的，一位同事嚷着自己的电脑网络有问题，叫SA 过去看，其实是自己输错了网址，这种低级错误也找SA 去解决，令到SA 俨然一个打杂的小兵。 先介绍下SA 的工作吧，包括但不限于，机房的建设，这个并不是别人眼中很容易的工作，单是布线这个体力活，就很有技巧了，如果简简单单地乱布线，将来机房一定乱糟糟 的，根本没人敢进去。机房的网络部署，更是至关重要。想想，如果服务器运行正常，但网络断了，那无论架构师设计多好的高可用架构也是于事无补的。 google 的数据中心，更是打出了低碳的口号，可见，机房的建设也同样是SA 需要付诸努力的。SA 拥有服务器的 root 权限，至高无上的权力，一个命令可能毁了一个网站！！我就真的试过运行 rm -rf / ，恶梦一样，不过也从此学会了教训，SA 一定要细心，蜘蛛侠也说了，“great power comes with great responsibility.”，哈哈。SA 还负责了操作系统的安装，应用软件的安装及配置啦。svn 或其它什么代码管理工具的，通常也是由SA 掌管的，你看，代码都掌握在手里了，哈哈。DB 嘛，也是需要操作系统来承载的，SA 同样也拥有其服务器权限，DB 也掌握在手里了，哈哈。就是因为这种特殊的权限，什么杂事都会找到SA 的头上，令到SA 的时间管理变成一种学问。由于SA 对于系统底层的认知，也可能于应用方面，对于应用软件作出符合自己业务的hack 。同样，保证系统的安全也是SA 的职责，当然，可能也会有一个叫安全工程师的职位存在。。。SA 的职能真的很多很杂，我一时也想不到了，就此打住吧。 当然，其实一个SA 并不能完全负责了这些东西，我也只是远程地维护服务器而已，并没有亲身去摆弄服务器。平时也就处理一下烦杂的业务需求，管理一下应用系统的服务器，偶然偷懒一下而已。 SA 要关注的知识点，同样较多，多而杂，也不可能每个点都很深入，追求的就是广吧，呵呵。操作系统，计算机网络，计算机原理，C语言程序设计，编译原理等，都 掌握就最好不过了，哈哈。别以为SA 平时就弄弄服务器命令，不会编程，其实我们多少还是会一点的，可能就是不够熟练而已，程序出问题的时候，说不定还要SA 去走读代码来解决呢，不是说开发不聪明，而是有时从一个旁观者的角度去看问题，真的是可以跳出那个 box 的。别以为SA 就像工人一样在处理烦杂的事情，一个聪明的SA 不会有2 次重复劳动的机会。或脚本，或走捷径，总之用自己的方法去偷懒，一个足够懒的系统管理员，才是真正优秀的系统管理员。perl 的发明者，不正是由于懒而发明了perl 么？ 我为什么要喜欢并从事着SA 的工作呢？其实我小时候还是喜欢开发的，慢慢地，我发现，其实开发有很多都是一些重复的工作，而且对于所谓的高级语言来说，无非就是读取某些地方过来的一 个数值，然后if else 一下，然后调用一下某个组件，然后展现出很貌似很漂亮的效果。其实，我觉得，这个没有什么技术含量。当然，我的说法其实过了一点，程序开发还是有很多更加 灵活的地方的，我最喜欢那些会利用小技巧设计程序的开发人员了！然后，我就发现，原来SA 可以如此地接近真相，SA 可以更从底层地去解决问题。同时，SA 的知识接触面也是很广的，我喜欢了解更多，选择自己喜欢的点去深入。 我现在更想通过hack 一些东西来令到业务有增长的，这是从细节去令到一件事做得好。其实以前我也有小hack 过一下 proftpd 的，那时候就觉得实在太有趣了！！另外，我现在接触的知识，倒有点像架构师的内容，这是从宏观的角度去把一件事做好。一个小聪明，一个大智慧的分别，其 实，我更喜欢小聪明，呵呵。 ——————————- 末了，还可以说一个职位出来，叫，架构师。 以前我的大学有一个课程，叫做软件架构。这个也是叫架构，但与我所说的架构，可能不是一回事了。里面介绍的是，一个软件的设计要如何如何，如果换作 一个web 产品，负责整个产品的开发设计的工作，这个职位，应该叫web 设计师。我很肤浅的经历告诉我，这个职位由资深的开发工程师来担当足以。 我在这里说的架构师，是指系统架构师。这是个虚无的职位，对于技能没有一个定性的标准。简单地说一下吧，系统架构师，通过合理的低成本，应用软件的 选型，服务器选型，网络拓朴设计，通过各种组合，构建出一个高可用（99.99% 简称4 个9，为合格标准？），高并发（c10k？），高负载的大型系统。 系统架构师虽然是从一个宏观的角度去设计整个系统，但是关注的却是整个系统的方方面面，小至几个字节的网络传输，几毫秒的网络延迟等。高可用并不那 么容易，负载均衡，健康检测，故障屏蔽并不可少。在地大物博的中国，或许还要考虑南北互通的问题。分布式的应用，更要考虑数据一致性的问题。这一个一个的 问题，钻进去都是一个个深不见底的洞。 系统架构师，需要的是经验的积累，不断实践尝试，不断地与时俱进而来的。 ——————————– 总结一下，如果把技术当成自己的一个谋生的工具，那么真的没必要学得那么深，做一两个项目就转型做管理就算了。 我一直认为：程序员的领导管理程序员，成功率只有50%，因为不是说技术做得好管理就做得好，很多人真的只能埋头钻研技术，但于人前就不懂表达自己的。但如果不懂技术的领导来管理程序员呢，对不起，门都没有。（好像在哪里看过。。。不是我的原观点啦，只是我十分赞同） 陋见陋见，仅以我幼稚的看法，来表达一下心中极度郁闷的情绪。