Mobabel

Just One Pure ITer

Mobabel Blog

[转]研发团队效率低下，究竟是谁的锅？ 0

Team

[转]研发团队效率低下，究竟是谁的锅？

研发效率未达预期是很多团队都会遇到的问题，项目延期的情况也并不少见。其原因也是多种多样，可能是因为遇到某个技术难题解决不了，可能是因为需求发生了变更，可能是因为设计提出了修改方案等等，表面上总有各种各样的突发情况导致延期。 那延期之后要不要追责呢？一个问题留给大家。然而不论是否追责，这并不能从根本上解决研发效率太慢的问题，我们需要找出更深层原因，总结经验与教训，避免再踩入同样的坑。

[转]美团CAT监控系统–分布式系统监控那些事儿 0

System Monitor

[转]美团CAT监控系统–分布式系统监控那些事儿

分布式系统已经诞生了很长时间，随着计算能力和存储价格的降低，我们见证了分布式系统大爆炸的时代，现代互联网公司规模都变得异常庞大，系统也变得越来越复杂，给监控工作带来了极大的难度：海量日志数据如何处理，服务如何追踪，如何高效定位故障缩短故障时长……

[转]MySQL每秒57万的写入 0

MySQL Optimization

[转]MySQL每秒57万的写入

摘要： 一、需求 一个朋友接到一个需求，从大数据平台收到一个数据写入在20亿+，需要快速地加载到MySQL中，供第二天业务展示使用。 二、实现再分析 对于单表20亿， 在MySQL运维，说真的这块目前涉及得比较少，也基本没什么经验，但对于InnoDB单表Insert 如果内存大于数据情况下，可以维持在10万-15万行写入。

[转]美团点评运营配置平台的设计与实践之道 0

MS Design Princinple

[转]美团点评运营配置平台的设计与实践之道

移动终端的开发变得越来越复杂，随之而来的是对 C 端动态化要求越来越高。动态化需要对 C 端里的基础配置、运营资源进行灵活的管理。如何在版本快速迭代过程中，满足业务场景的高效灵活变更？传统的解决方案无法满足这种复杂场景，美团点评基于自身移动运营的实践，打造了稳定、灵活、高效的运营配置平台。本文根据美团点评高级架构师蒋国宝在 QCon 上海的演讲整理而成。

0

MySQL Optimization

[转]MySQL的性能优化及自动化运维实践

1. DBA的日常工作 首先，我们来看看DBA的具体工作，我觉得 DBA 真的很忙：备份和恢复、监控状态、集群搭建与扩容、数据迁移和高可用，这是我们 DBA 的功能。 了解这些功能以后要对体系结构有更加深入的了解，你不知道怎么处理这些故障和投诉的事情。 所以我们要去了解缓存/线程、SQL优化、存储引擎以及SQL审计以及锁与实务、体系结构更深一点，就去研究内核原理和源码定制，DBA有这么多工作，他们就像一个小怪兽一样等着我们去解决。 今天我站在更加全面的角度跟大家分享一下我觉得我在这一年多DBA工作当中的经验，希望可以给大家带来启发和帮助。

[转]分布式之elk日志架构的演进 0

Theory & Solution

[转]分布式之elk日志架构的演进

1. 日志系统的必要性? 最早定位生产问题，就是连上一台机器，然后用使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。如果发现不在这台机器上，就去另一台机器上查日志。有经历过上述步骤的童鞋们，请握个抓！ 然而，当你的生产上是一个有几千台机器的集群呢？你要如何定位生产问题呢？又或者，你哪天有这么一个需求，你需要收集某个时间段内的应用日志，你应该如何做？ 为了解决上述问题，我们就需要将日志集中化管理。这样做，可以提高我们的诊断效率。同时也有利于我们全面理解系统。

[转]Java内存模型原理 0

Java Memory Model JMM

[转]Java内存模型原理

这篇文章主要介绍模型产生的问题背景，解决的问题，处理思路，相关实现规则，环环相扣，希望读者看完这篇文章后能对 Java 内存模型体系产生一个相对清晰的理解，知其然知其所以然。

0

Team

[转]以 Data Driven+Ownership 组建高效团队

1. 效率差距 在加入小红书之前，我曾先后在百度、知乎、Facebook、Airbnb 工作。今天就想分享我在这过去的十几年间看到过、经历过的不同公司在“效率”上不同做法，以及一些自己的总结。 “从硅谷到中关村到底有多远？”大家在十年前觉得硅谷是技术型公司的圣殿。但是，今时今日中美互联网公司，这些差别都变得非常小。

[转]深入解析Java锁机制 0

Lock

[转]深入解析Java锁机制

1. 前言 Java提供了种类丰富的锁，每种锁因其特性的不同，在适当的场景下能够展现出非常高的效率。本文旨在对锁相关源码（本文中的源码来自JDK 8）、使用场景进行举例，为读者介绍主流锁的知识点，以及不同的锁的适用场景。Java中往往是按照是否含有某一特性来定义锁，我们通过特性将锁进行分组归类，再使用对比的方式进行介绍，帮助大家更快捷的理解相关知识。下面给出本文内容的总体分类目录：

[汇总]其他程序员的思考 0

Collection

[汇总]其他程序员的思考

1. 技术 入行 14 年，我还是觉得编程很难：给大项目写代码没意思还危险 写代码很简单，但写好代码很难 编程的精髓是“创造” 打造高效试错的环境至关重要： 理想的编程体验≈“刷题” 避开代码完美主义陷阱 技术很重要，但“人”也许更重要：在软件开发领域，“单一职责原则”（全称为 Single responsibility principle，后简称为 SRP）是一条非常著名的设计原则。它的定义很简单，一句话就可以概括：“每个软件模块应该只有一个被修改的理由。理解 SRP 原则的关键，在于先理解人以及人在软件开发中所扮演的角色。如果缺少了特定的组织规模（也就是“人”）作为前提，空谈微服务的各种技术优势和那些花活，纯属本末倒置。 求知若渴是好事，但也要注意方法。 越早开始写单元测试越好。 程序员最大的敌人是什么？软件生来就是准备被修改的（不然你猜，软件为什么叫“软”件？）。产品经理以及不稳定的需求不是程序员的敌人。复杂度是最大的敌人 。 来看看那些导致项目复杂度不断增长的要素： 不断增加的新功能：更多的功能等于更多的代码，更多的代码通常意味着更高的复杂度 对高可用的需求：为了实现高可用，消息队列等额外的技术组件和代码被引入 对高性能的需求：为了提升性能，缓存和相关模块代码被引入，部分模块被拆分后，换成高性能语言重写 一再被推迟的重构：因项目排期过于紧张，迫在眉睫的重构被一再推迟，技术债越积越多 忽视自动化测试：没人写单元测试，也没人关心测试 减缓复杂度增长的过程   虽然复杂度总是会不可避免地持续增长，但有许多实践可以减缓该过程。如果每个人都能做到以下这些事，复杂度就有可能被长期控制在合理范围内： 精通当前编程语言与工具，写整洁的代码 使用合适的设计模式和编程模式 对重复代码零容忍，抽象库和框架 适当运用整洁架构、领域驱动设计思想 编写详尽的文档和注释编写规范有效的单元测试...