工作点滴

工作后的记录

企业用工困境两例(一)

站在万恶的资本家角度来组织管理工作和思考后,目前遇到的两个无解的问题,记录下,看看未来会不会有更好的解决

一是女性员工因怀孕生子,引发的职场女性在招聘和用工过程中的被区别对待的问题

首先我们不质疑任何涉及政治正确的话题,不管是站个体还是国家,都应该鼓励和支持生育,保障员工利益。怎么保障?一是对生产的女性在怀孕期、产假期和哺乳期提供必要合理的假期和薪资保障,以及孕产妇丈夫在三期内因陪同照顾等需要的假期和薪资保障,保障的钱怎么出?我认为作为国家政策,应该由国家统一调配,对所有人以某种方式收取一个基金池来保障,可以是强制全员生育保险,可以是企业、社会或个人税收中的一个组成部分,或者是印钞、国家公共开支里预留的一部分,否则都由当事人所在的企业方负担,那企业作为盈利机构,必然会趋利避害少招或不招育龄女性,惩罚少招不招女性和奖励多招女性的政策本质上还是纳入统一调配

然后是在政策保障外,女性的职位持续问题。对于类似简单培训交接就可以上手,且量大可互换性高,如生产线工人这样的岗位,女性生产前和生产后都可以快速放下或拾起,只要做好工作时长和安全防护等保障,对孕产妇个人说影响不大,对企业方来说也就是阶段性人手安排的调整。而对于某些专业岗位,需要长期的专业学习或对业务的了解,且岗位数量单一,如公司的财务经理,产假期带来的岗位空缺就非常麻烦,不可能强迫或引导产后女性员工在产假期来工作,这个违背基本道德,且在产假期对新生儿的照顾培育也不会有足够精力还去工作,如果用合格的其他人来补充,因为岗位数量单一,企业不太可能有现成的备岗人员,另行招聘并适应岗位工作的话,等休产假员工回来上班后,两个人一个岗,谁去谁留?让休产假的员工转岗,这样跟支持和鼓励生育完全违背,女性会不敢生育,让另行招聘的员工离岗,不说另外带来的招聘和用工成本,如果来顶替的人知道只是临时顶班,事后必被放弃,还会有多少人愿意来接手

更深层次的问题,是整个职业成长和企业的业务规划持续性。女性员工为了生育,孕期加产假加哺乳期,生理上的变化对专注度和情绪波动都还是有不可忽视的客观影响,以及,在需要持续学习成长的岗位上,脱岗半年后回来要跟上新节奏就需要花额外精力。从企业角度,如果准备生育的员工是业务线上的关键人物,缺席会导致业务线无法推进甚至无法维系,怎么办。孩子出生后还会有更多体检疫苗或生病照料的请假,这个对男女员工都一样,所谓 35 岁危机也是从万恶资本家角度看,时不时需要顾家的大龄同事,显然不如能专注投入甚至可以任意加班加点的牛马好驱使,要不是看在经验的份上,巴不得都优化毕业掉

二是大城市生活成本持续升高,年轻人留不下来,企业面临招工难,流失率高,又不得不维系高强度招聘的问题。拖拖拉拉写不完,回头另开一贴

读书笔记:OKR 工作法

OKR 工作法:https://book.douban.com/subject/27132072/

之前有各种看过一些关于 OKR 的材料,公司也在几年前尝试过一段时间的 OKR 管理,最终并没有很好的执行下去,读书还是要有所得,记下来看看。这是一些很个人化的点,不是全书摘要

目标 Objective

首先是目标,合适的周期应该是一个季度左右的目标,太长的目标(比如一年以上)的应该叫愿景,太短的目标(比如一两周)的应该叫任务

愿景或使命的常用格式是:

我们通过(什么样的价值主张)在(什么领域或行业)(改善人们的生活或减少人们的痛苦)

目标是一个期望,且不应该跟数值挂钩,跟数值挂钩的应该是关键结果

关键结果 Key Result

关键结果除了可以数值量化,也需要精确定义完成标准,用于客观评估完成与否,且这个数值不应该被外界大环境的波动影响

关键结果需要设定信心指数,为了保持有挑战性,不应过高,同样的为了避免定的完全不可能让大家放弃尝试,也不应过高,在 5/10 作为初始值比较好

关键结果需要每周更新信心指数的变化,为什么变化

执行

每周更新团队的 OKR 卡片,列举为了完成目标需要去做的最重要的事情,一般 3~4 件,过多的事情说明大家都没有聚焦在目标上,杂事可以做但没必要列出来

周五下班前更新进度,给团队展示大家对目标完成的新进度,保持团队一直是积极的态度

使用 Scrum 等敏捷开发的思路来配合 OKR 的执行,有更明确的周期考量

我们在过去尝试中的坑

在目标制定的过程中,缺少参与度,各自列各自的,也没有充分的讨论和投票来明确目标和关键结果

对于关键结果的完成评估方式尺度不一,有可明确的也有没法明确的,初始信心度在不同团队也没有统一

没有很好的日常跟进进度,周会和周报跟 OKR 内容脱钩了

在具体执行中并没有使用 Scrum 等方式来推进更细粒度上的项目管理

期望替代 KPI 来做绩效考核工具,然而 OKR 的本意并不是一个绩效考核工具,而是一个工作方法(虽然执行的好日常沟通和跟进中就已经能得出绩效结果了)

产品的一致性很重要

上周,在评审一个旧功能的改造过程中,发现同一件事,可以在多个场景适用,可以在单独的管理页面来管理,也可以在正常的流程中通过弹窗等方式管理,那么,同样的交互,如增删改,给用户的感觉,其内在逻辑和操作交互就应该都是一样的

对产品而言,保持逻辑一致,有助于降低用户认知成本,提高使用效率

对设计而言,是设计规范的一致性体现

对开发而言,能更好归纳总结需求,实现时一并处理,减少重复(并避免给未来留坑)

无谓的感动只会显得无能

感动一般是发生在花很大的成本做成某件了不起的事情后,大家觉得投入的资源很感动

但是如果并没做完事情,投入就一文不值,再努力也不会让人感动。当然,做完事情可能是事情做成功,或者做失败但是从里面学到了足够的东西

如果仅仅只是自己觉得花了很大成本,其他人发现有更简单高效的办法,那也谈不上感动,只会让人觉得做事不麻利,或者蠢

成长的笔记

毕业这么久,自己做事,带人做事,带团队做事,一路过来有很多感悟,又好像说不清到底成长在哪里,最近看了知乎上一个回答,深有感悟,归纳的挺好

原文在 https://www.zhihu.com/question/50539172/answer/121771903 ,答主 Cat Chen 之前在度厂工作过,似乎有过一面之缘,最近看他的 Blog 和知乎回答,在这类思考上还是走的挺前的,跟从之

回到主题,在 Cat Chen 的知乎回答里,把工作中人的能力分成三块:Technical、Direction、People,用中文对应大概是 技术能力、方向把控能力、沟通能力

其中 技术能力 是个人可控,可以独立成长,并且很容易评估成长程度,同样一件事给一个人完成,有人一天就能完成的很好,有人花一周还弄的磕磕碰碰,前者比后者强,这个是绝大部分人都可以达到的境界

而对于 方向把控能力,我们从小到大接受的教育都比较忽略这一点,更多的时候我们都是在指定了问题的情况下怎么去解决问题,而真的把一个开放问题丢到面前,必须要自己找方向时,就挺难了。大多数人在这个阶段就被淘汰了,或者鸵鸟政策自己看现在自己可以做什么就去做什么,自我安慰只要我一直在努力那必然也是有成果的,殊不知方向错了做的再多都没用,还可能有反作用

在有 技术能力 基础和 方向把控能力 上,可以更好的与 沟通能力 做同步成长。对自己的反馈上,沟通能力好,才可以更事半功倍的提升自己的技术能力,不然有些事别人点拨一下就可以解决的问题,自己可能要花十天半月还不一定摸到门路;沟通能力好,才有机会获得足够的信息输入,且信息来源可靠或有可靠性分析,进而影响方向把控能力。对外而言,不是所有事情都可以单枪匹马搞定的,那就涉及到怎么去拉到其他人来帮自己做事情,除了上级死压下级这类没法反抗的情况,绝大部分时候涉及到怎么让人「信服」自己的事情,信服的基础是你证明你能做好这件事(技术能力),并且你做的这件事对别人有好处(方向把控能力),别人才会心甘情愿的追随或听从你,否则只会出现「唉我这个事很靠谱你们怎么都不理我」或「你们一个个明明有空为啥都不愿意听我讲跟我做事」的情况

干活碎碎念

0x00 有客户反馈有同行的某个功能比我们强大, 数量上限远超我们
0x01 对于这种违反科学的说法我们显然都是不信的啦, 平台的限制还能破?
0x02 但是这客户也是个超大的店, 不像是睁眼说瞎话的小白, 那就去验证下?
0x03 为了测试大数据量, 让产品妹子把帐号贡献出来我们灌几百个商品进去
0x04 笨狗一念之差, 偷懒直接用同一个图和测试商品的标题灌了几百个
0x05 测试完了都没事, 第二天一早起来产品妹子发现店被淘宝封了…
0x06 封禁理由是 “重复铺货, 影响交易安全”, 而且是永久封店
0x07 这下玩脱了… 只能去申诉, 找平台方他们也管不了淘宝主站的安全策略
0x08 申诉还要买一份当地的报纸举着带日期的头版拍照来各种证明身份
0x09 于是产品妹子说这好像是她多久多久以来第一次主动花钱买报纸?
0x0a 还好拍照不用像手机淘宝开店那样要摆各种羞耻 Play 的奥特曼姿势
0x0b 到现在好像还没被解封, 我真是有罪啊

0x10 说回那个测试本身, 客户确实没说谎, 是平台方逗逼大了
0x11 说好的 xxx 个限制, 发现在某种奇葩情况下可以无上限的添加
0x12 这特么就是个 bug 吧… 我们果断去投诉反馈了
0x13 要是平台方敢答复说这其实是个 feature, 特么劳资一刀捅死他

0x20 其实往淘宝店灌测试商品的正确姿势应该是去抓豆瓣数据做填充
0x21 比如抓个书单, 把书名和简介当商品标题和描述, 还能有不一样的主图
0x22 只要别抓太狠, 豆瓣都不会封, 简直完美
0x23 这个想法唯一的漏洞是, 在淘宝买书或音像制品是要有资质证明的
0x24 那么只能找个没限制且不会因为类目乱放的其他类目弄上去了
0x25 考虑到类似需求以后还是可能用的上, 还是不要每次人肉瞎凑了
0x26 正儿八经写了个放到 GitHub 上: https://github.com/whusnoopy/taobao_uploader

0x30 淘宝经常出些逗逼的问题, 给他们提工单, 答复的人也都是群逗逼
0x31 比如明明信息提供全了图都截了人家回句你提供下某某信息
0x32 去你大爷的上面写的清清楚楚你敢看完了再这么回么
0x33 比如经常绕着绕着就变成了 “这个问题你咨询下淘宝客服”
0x34 擦你妹夫就是因为那帮兼职客服什么都不懂才来问你们的好么
0x35 这一行做久了对淘宝和阿里系的评价只能是一坨狗屎
0x36 不好意思好像我刚侮辱了下狗, 而且我又情不自禁的爆粗了
0x37 除去只能靠平台方改业务逻辑的, 大部分问题最后都是试出来的
0x38 傻逼问题见多了, 奇葩解决经验一多, 自然就变成了老司机

0x40 平台方有个 BUG 反馈的大群, 同行们基本都在里面
0x41 天天也有各种人出来哭爹喊娘说这个问题怎么办那个问题怎么办
0x42 偶尔心情好, 加上透露解决方案也没啥损失, 就会指点一下
0x43 有时候居然还有傻逼同行会质疑我们给出的原因和解决方案
0x44 倒腾一大圈最后发现还是我们说的那样, 真心懒得理这帮白眼狼
0x45 好心好意告诉你, 居然敢质疑我们的经验, 很想做个 meme 图

论打折, 我不是针对谁
而是说在座的各位
都是垃圾

0x50 之前写一系列客服趣事时记录了很多逗逼的卖家
0x51 其实我们那些逗逼的同行也有很多欢乐可以写出来开心开心
0x52 比如今天有人跑群里说我的分怎么就被扣了, 都没有差评的
0x53 仔细一瞅他的应用就是拦截差评师的, 真是个黑色幽默
0x54 当然这个事估计更多的是淘宝的坑, 只是刚好赶上这么个名字

给公司做了个新首页

给公司做了个新首页, 其实并没有什么特别的更新需求, 主要是招聘客服妹子时别人事先搜不到公司首页也没法了解你们是干啥的, 成果见此: 杭州美登科技有限公司

下面记录下开发过程, 学了很多 HTML/CSS/JS 的知识, 更新了下大脑里的旧内容, 对前端不同浏览器兼容性的坑又踩深了一点

框架部分

看了下现在流行都是单页应用, 开发起来也比较简单, 基本的文件结构和 HTML/CSS/JS 布局参考 CodeCademy 上的 Make a website 课程, 配色取了下我们新 Logo 上的几个色, 用 Color Hex 查了下相应颜色变深或变浅后的色值, 直接套上去的

页面布局和 CSS 自学加抄袭了下 Bootstrap 的 container/row/col 布局, 不过因为是需要啥添的啥, 不是一上了就想好整个框架, 抄的又不到位, 尺寸各种不对, 后来发现原来要再 CSS 一开始就把 box-sizing 设成 border-box, 后面才是熟悉的盒模型的大小

没有分页, 不同内容就大色块大模块, 导航没用 a 标签的锚点, 而是用了 jQuery 的 scrollTop 方法来让跳转过程有动画效果, 这个很简单, 只是最后测 IE 时发现只让 body scrollTop 是不行的, IE 里滚屏应该滚 html. 就是得这样: $("body, html").scrollTop(...);

导航

因为是单页分不同模块, 在导航栏上更新当前活动模块, 就在 JS 里通过监控 scroll 事件来更新 navbar 里不同 li 的 active CSS, 一开始想着优化性能, 对不同模块的 div 的位置做了预处理, 但是偶发性滚屏位置不对, 一直也没找到原因, 加上页面上有高度动态变化的可能, 最后还是老老实实每次都现算, 这么点性能差异应该也无所谓, 反正测试的各种设备都没感觉卡

因为导航栏的跳转也用了 scrollTop 方法去滚屏, 会触发同样的监控事件, 为提高性能并避免因为 CSS 里全局用 em 标注尺寸导致可能出现换算后奇怪的 1 像素偏差引起的 navbar 当前活动模块判断不准, 先是加了个 scrollTo 的全局变量来判断滚屏事件来源, 但是这个处理在大屏幕上可能有问题 (因为屏幕尺寸比模块 div 大, 说要 scrollTop 到最后一个模块, 但实际的 top 还在上一个), 最后用的 setTimeout 设置延迟事件来区分了是因为点导航栏引起的滚屏还是用户自己的滚屏

顺带说一下, 看了下 Bootstrap v4 alpha 的文档, 导航栏滚屏和监控滚屏事件更新导航栏活动 li, 这俩需求都已经有现成的了, 见 Scrollspy

弹层

职位描述用的弹层实现, 弹层的 Modal 用的 lightbox_me, 一切都很顺利, 只有最后测试在 iPhone 上有一定的概率弹飘, Safari 和 Chrome 都会出现, 原因未知, 估计和 slick 哪里冲突了

弹层这个其实 Bootstrap 里的 Modal 支持也挺好的

幻灯片

自动滚屏展示图片, 一开始人肉实现, 只用支持自动滚动什么的也还好, 后来想带支持移动设备上触摸拖动, 看了下估计自己搞太费劲, 还是老老实实换用现成的, 比较了几个后最后用的 slick, 自己重载了部分 CSS 来替代默认的主题

slick 会把要要滚屏的图片或 div 在最前最后做一次复制方便跳上一个或下一个, 但是似乎会导致某些浏览器下带来副作用, 其对容器 div 做了 class 修改, 还是多套了一层防止出现奇怪的问题

Bootstrap v4 alpha 里也看到有直接支持的这个功能, 见 carousel

在照片上加文字, 先试了下 OS X 下的预览做修改, 没法保证不同的图片上蒙层大小和位置一致, 搞不定就让 tuying 去帮忙用 PS 加, 后来想这事用 CSS 估计更简单, 等 tuying 说用 PS 改好图了我说我这边 CSS 也调通了, 不知道会不会被捅死

地图

联系我们那用百度地图 API 来嵌了个地图上去, 写的时候感觉百度地图 API 使用文档组织的还不如淘宝开放平台那个渣, 倒是示例还比较多, 可以各种连蒙带猜人肉测试

地图上加标记弹消息, 如果全用现成的, 对话框的起始点是标记点的标记下方, 很奇怪, 裸写 HTML 反倒是符合预期的标记上方

加上来的地图默认支持滚轮缩放, 不关掉的话电脑上滚轮滚到这里就变成不停缩放地图而不是滚页面了. 关掉滚轮缩放后要加一个显式的缩放按钮组件让电脑上还是能缩放地图, 手机上他会自动加上的其实无所谓, 不过手机上双指缩放这个好像没法禁, 如果页面拉大了视野内都是地图, 那只能重载页面了 (如果这个问题有更好的解决办法也欢迎在下面留言告诉我)

移动设备适配

适配手机, 问题不大, 习惯了 @media (min-width...) 这样后控制下尺寸就好, 不过布局也没法完全流式, 弄了个 640px 的 min-width, 反正 iPhone5 的横向物理分辨率都有 640 了, 捏一下 scale 就好

在电脑上 Chrome 的开发者工具里 device mode 和实际设备上的表现有明显差别, 还是得真机测过才靠谱, iOS 设备大家都有, Android 那边刚好公司新买了个红米 Note2 当测试机, 除了系统自带浏览器外一口气另装了 9 个各种浏览器, 测下来有一些小的不一样, 但是整体兼容性良好, 比 iOS 还靠谱. iOS 里的 Chrome 兼容性很奇葩, 估计跟调的还是 Safari 的 webkit 核有关 (比如 Modal 飞了). Firefox on Android 缩放后会比较奇怪, 导航栏的底色还是没 scale 前的宽度, 不过应该没多少人蛋疼到去手机上用 Firefox 吧

浏览器兼容性

主流的浏览器, 开发测试就在 Chrome 上, 这个倒是不用担心, Firefox 最后找人看看没问题, 应该也还好, 关键是 Windows 下那一坨 IE 以及改了不知道是 webkit 核还是 IE 核的国产浏览器

用 Win10 测试, Edge 表现跟 Chrome 什么完全一样, 不用任何改动. Win10 下默认是 IE11, 然后这货的开发者模式可以模拟 11,10,9,8,7,5 (我也不知道为什么没有 6 但是有 5), 测试覆盖面是够了. 前面那个所有 IE 核都影响 scrollTop 的问题就不说了, 其他问题上 IE9+ 还是挺靠谱的现代浏览器, 都没啥要处理的, 从 IE8 往下, 那都是泪…

到 IE8 开始出的问题, 先是 container 布局控不住尺寸, 放狗搜了个 respond.js 勉强搞定, 然后是没有弧角 border-radius, 这个没有就算了吧, 有些按钮从圆变方还挺带感的, 最后折腾到 IE8 居然显示还勉强凑合, 真是感动到泪流满面

再往下到 IE7 就更多奇葩了, 比如 float:right 会换行, 非得把 float 的 div 放到同级元素的最前面才行 (本来想强迫症的让页面不带任何 CSS 也可读的结果还是没做到裸内容和实际显示完全一样), 比如不支持 display:inline-block, 改成 display:inline 搞定, 还不支持 box-sizing 导致自己写的 col 宽度用百分比的话绝对被折行, 心想用 IE 的只能是电脑, 然后现在电脑屏宽没有小于 1024 的了吧, 估算了下直接硬减了个百分比实现, 不支持 border-radius 另外 padding 什么的实现也很奇葩, 这些就算了, 显示不正常就不正常吧, 勉强能看就好了

主流浏览器没问题, IE8 基本没问题, IE7 甚至 IE5 只要宽容度好一点也能接受, 最后调成这样真的有忍不住学樱木花道来一句 “我真是个天才” 的冲动

为啥要自己作死而不用 Bootstrap 之类的现成框架?

本想写 FAQ 的但不知道看客们会有什么问题, 估计最大的疑虑是为啥不直接用 Bootstrap? 所以就把子标题改掉

我的经验是如果要基于 Bootstrap 弄出自己的风格, 还是要对他那套东西比较深入理解才行, 光重载 navbar 什么的就挺麻烦的, 而我这点需求自己写一个的代价也不大, 关键是可控, 同时自己也能把前端的技能点给各种点亮. 另外就是想要的很多功能都是 Bootstrap v4 里才有的东西, 但这货现在才 alpha, 而且明确说了只从 IE9 开始支持, 浏览器兼容性要死人的

2014 年度盘点

每年的惯例要保持, 不过本篇其实没来得及在 2014 完成, 那就在 2015 的开始尽快写完, 然后偷偷把时间改到 2014 年来发吧

流水账

一月, 从阿里离职, 加入 “我朋友和他的朋友们的公司”, 哦哈哈, 去了趟天子地, 回家过年
二月, 过年值班, 陪阿里开始在千牛上折腾
三月, 折腾新办公室装修
四月, 陪喵去桐乡见同学然后去乌镇小玩了一圈, 跟公司坐船游了次西溪, 驾照换到杭州
五月, 团队去千岛湖休整了一段, 第一次违章, 跟车闯红灯被扣六分
六月, 千牛团队自己发现玩脱了回到我们一开始提的方案, 几个月的折腾白做了, 看世界杯
七月, 继续看世界杯, 德国终于冠了, 喵爸妈来杭州, 陪玩
八月, 算是跟家里都谈好了, 那么就准备领证, 去看房子, 公司去厦门玩
九月, 还在折腾买房的各种问题, 把户口档案迁来杭州
十月, 去爬了一次西湖旁边那堆山
十一月, 第一次以服务商身份参与双十一, 去北京取掉公积金剩的钱
十二月, 平淡无奇的双十二, 挖个新坑自己跳, 各种折腾过年回家婚礼的事

工作

在公司补贴的情况下把自己的生产工具换成了 rMBP 13, 日常使用已经倒向了苹果阵营, 虽然还有留着 X200 和虚拟机跑 Win, 但大部分时间都没在用了. 基于 UNIX 的 OS X 在开发上确实要方便很多, 各种环境直接在本机搭建测试, 不用再跑虚拟机, 而且需要的开发工具也还挺完善的

上半年大部分时间在跟淘宝的千牛死磕, 耗了一大段结果被晃点了, 不过也算是通过这个了解了怎样在目前团队去开发测试以及跟淘宝扯皮. 下半年一是继续我们的每年一重构, 重构一整年的节奏, 把影响开发效率和性能的一部分主体重构了下, 然后到双十一双十二的时候跟着做性能调优. 快年末时去尝试了些新东西, 不过目前看效果都还不咋滴. 全年做了各种辅助生产力和客服效率的小工具, 现在已经不是手里有锤子看谁都是钉子, 而是看哪里都是钉子要给在这边呆着的人造把好锤子

生活

今年好好呆在去年租的房子里没挪窝, 从阿里离职后办了小区里每月 100 的停车包月, 最后发现还是要卡点回去才能有空位, 忍了半年受不了还是到小区后有人看守露天停车场一个季度 800 块钱放着了. 全年花费在车上面保险和停车的钱随便哪个都比油钱多的样子, 由此可见全年大部分时间还是趴在杭州城区, 去二保的时候才开了八千公里不到, 太浪费了

平日该吃吃该喝喝, 衣食住行基本没操过心, 所以在生活上似乎都想不起来能记的点

学习

今年看了些杂书, 很多是关于交互的, 主要还是想自己如果去做东西, 到底应该做什么样的东西才能跟目标客户互动起来, 怎样的交互设计是最不用让别人费脑子直接能获取到自己想要对方明白的那一点. 从大的方面说, 这个更像是去学习洞悉人性

闲时刷知乎, 看各种问答了解这个世界的丰富多彩, 也在了解不同的思维方式和各人偏好, 不过好像都没有什么特别的个人总结看自己到底提升了些什么

自己在技能树上乱点了一堆奇怪的点, 比如今年办公室装修, 跟着研究怎么布局啥的, 年末死猫君又召集搞票, 改用 Go 写, 又去看了下这个最近开始越来越火的语言

自己感觉这一年思维上最变化最大的是去阿里走了一圈, 再出来以一个合作方的角度, 去看阿里和围绕阿里的整个生态系统, 开始理解马云等领导层做一些决定的动机和结果, 虽然最终我还是不喜欢这个公司和这个公司里面的很多人, 但是既然还靠着阿里吃饭, 多了解下也没坏处, 世界这么险恶, 知晓他人的阴暗才能更好的走自己的阳光大道

锻炼

某一段为了督促自己锻炼, 还去买了 runtastic 的应用, 来测做俯卧撑/深蹲/仰卧起坐, 到冬天早上起来太冷, 后面也经常送喵上班, 也慢慢荒了, 而且按熊的说法, 我的锻炼其实各种不标准, 起不到太多锻炼的作用. 买车后骑自行车也少了, 常年放在公司胎都要没气, 拉喵出去骑车也是各种犯懒犯困

体重没有增加, 但是也没有下降, 到底是自暴自弃就这么样了, 还是继续给来年做个规划?

活动

得益于在灵活的小团队, 出游似乎比前两年多了很多, 只是因为我们为了避开人群高峰, 一般都挑工作日出行, 所以绝大部分时间都没能带上家喵一起, 这个倒是遗憾. 全年去了杭州西边桐庐的天子地爬山, 乌镇走马观花, 西溪湿地西区游船, 千岛湖自驾休整, 苏州一日自驾, 安吉漂流, 厦门访客, 城西爬山, 灵隐瞎逛, 大部分都没有记录, 只有去厦门写了一篇 厦门之行

杭州城很多可以玩的地方, 也只是在周末喵不用补觉的时候出去溜达了下, 来了一年半了, 反倒在 2014 最后一天陪同学去了趟灵隐寺景区而且还没进需要单独买门票的寺

败家

今年最大的支出项是买房, 还记得快十年前第一次来杭州, 当时感慨怎么房价就上万了, 毕业后一年拿个十五万应该算不错了吧, 结果现在一看, 靠谱点的房子没个两百万根本拿不下. 其他的支出大头似乎就是在准备婚礼的各项事情. 本年度没有大的数码产品败家行为, 给喵买了个 iPad mini2, 给喵换了个红米 Note, 买了几块 SSD 和移动电源

继续坚持了一年的记账, 在随手记上不知道又多了多少条目, 也得益于随时记账, 很多事情过去了还能记得起来

理财

去年的投资分布是 银行理财/余额宝/美股/一些人情借款. 今年因为打算买房, 把美股都出掉换回来了, 扣掉各种转账手续费收益能有 15%? 本金不多, 其实也没赚几个钱. 发现银行理财利率也不高, 流动性也差, 今年把这部分钱换到了 P2P 借贷上, 投资项目比较分散, 把周期和风险摊开来, 保证自己能在有需要时能比较快的回钱. 余额宝和活期只留了保证基本的流动性的额度, 主要还是买房后没什么钱, 也没必要保持太大份额的流动性资金. 人情借款基本照旧, 果然是人情

理财上还是走的懒惰路线, 没去折腾, 因为懒得折腾和没时间精力去折腾, 有很多钱事后看倒是可以赚, 但是事前谁知道呢, 没有那个胆去博. 安心点 (其实就是不求上进) 的安慰自己 “命里有时终须有” 吧

双十一技术篇

去年我还没过来, 据说系统最后是没扛住双十一的大压力崩了, 今年提前好久开始准备, 底线是系统一定要扛住, 准备过程中列了下可能的风险点, 主要是

  1. 系统处理能力
  2. 用户流量出口
  3. 淘宝调用流量
  4. DB 写磁盘压力

挨个分析下

  1. 系统处理能力
    这个反倒是小事, 我们自己的吞吐能力从来没出过问题

  2. 用户流量出口
    今年年初开始就把静态内容放到了七牛上, 自己的流量压力小了很多. 不过盘算下到时候峰值可能还是会爆, 决定加带宽, 由于阿里云的奇葩定价策略, 单买 5M 带宽比买一台带 5M 带宽的虚拟机还贵, 于是我们就再继续买机器做分布式处理, 架构支持分布式就是好

  3. 淘宝调用流量
    调淘宝接口居然还算的是外部流量, 这是之前没仔细考虑过的地方. 看了下大头在读写商品详情上, 这个功能到时候估计怎么加机器都会不够, 提前准备了关闭部分功能做降级的开关, 反正也不是核心功能, 到时候看情况关掉好了

  4. DB 写磁盘压力
    其实 DB 本身是没那么弱的, 我们的主库机器把内存选到了阿里云支持的最大内存, 只是阿里云的硬盘实在是太差了, 一旦有大量持久化操作写磁盘, 磁盘 IO 就扛不住了. 这个我们提前对 DB 里的冷数据做持久化, 降低内存里的数据大小, 避免磁盘 IO 被写死

双十一前一天, 系统的 UV 大概是平时的两倍, 下午继续慢慢往上涨, 最高的时候到了平时的快四倍, 因为今年我们自己的带宽没卡住, 调淘宝接口也没被限流, 来做设置的卖家搞完就走了, 没发生堵塞. 事实证明如果在你的处理能力范围内, 尽可能快的做完事情把人送走才是正确的解决办法, 把一堆人扣在这里慢慢排队处理只会让事情越来越糟糕, 交通枢纽应该都讲究怎么快的把人疏散走, 而不是把人垒在自己这 (说的就是你, 帝都的各种地铁站什么的)

淘宝官方说的是双十一前一天晚上十点接口限流, 我们吸取去年教训在我们的系统通知里说下午六点就暂停服务, 这也算是一个缓解的思路, 让一些人提前进来处理掉. 不过下午六点后 UV 还是明显在涨, 一群又一群赶着想在双十一捞一把的小白新卖家各种不看公告不管系统通知一定要作死的卡点来做设置. 到晚上快十一点淘宝正式限流, 我们这边也按预案暂停服务, 挂通知安抚

凌晨的时候淘宝限流有放开, 其实当天人就不多了, 坡就偷偷的把服务给开了, 但是暂停服务的通知还挂着. 上午估计一堆人发现了系统还能用, 又塞过来各种调, 淘宝那边也大量返回报错和限流提示, 看了下好像也没有想的那么夸张, 坡一狠心把重试次数加大, 居然就直接扛过去了

按系统通知, 是打算在双十一第二天中午十二点才恢复服务的, 结果双十一当天顺利的出奇, 晚上十二点系统也还开在那, 可惜没想到卖家折腾了一天后发现系统还可用就疯狂的做一键重开恢复平时的活动设置, 瞬间涌进来了平日高峰流量的快五倍那么多人, 系统和流量都没问题, 但是 DB 跪在了阿里云这不靠谱的磁盘上. 只能暂停服务, 继续挂通知, 来的快散的也快, 估计过了十来分钟大家看没戏就很快散了, 然后把服务重新恢复. 第二天白天人一直就不多, 一直观察到十二点也没出现预期的瞬间高峰, 可能还是大家发现系统是可用的, 没有卡点来做恢复操作. 双十一就这么有惊无险的过去了

习惯性总结下

  1. 系统的可扩展性很重要, 关键时刻如果能通过加机器搞定的事情就去加机器搞定好了, 多花的那么点钱完全不是个事
  2. 对自己系统的能力和客户的使用习惯要预估好, 我们最后还是托大了下, 没预料到双十一结束后的那个瞬时高峰
  3. 阿里云还是要给力才行, 据说今年会全面换成 SSD, 到时候先开个 DB 从库上去当小白鼠, 靠谱了就全切

当然, 每年都有各种二逼卖家改错价找上门哭诉或要挟的, 这种作死行为完全拦不住啊, 不看通知不看公告不看系统提示你们真的是来做生意的么, 然后每年继续还有二缺天猫卖家双十一当天跑过来说你们怎么不能用我要给你们差评, 啊叻天猫早就通知了双十一当天只有官方工具生效的好吧, 更二缺的天猫卖家发现双十一当天普通折扣不生效了就去改原价, 然后晚上不及时改过来第二天凌晨到早上被人超低价狂买然后跑来说你们软件有问题乱改价我亏了你们怎么赔我, 切爱谁谁吧, 淘宝城在文一西路上过去拉横幅要跳楼找马总解决吧