Здравствуйте.
В первой части статьи я расскажу о некоторых стилистических «косяках», которые придают текстам характерный канцелярский унылый стиль. Вторая часть посвящена более серьёзной ошибке, которая, к сожалению, грозит в ближайшее время стать правилом.

При работе над облачными сервисами Webzilla мы уделяем очень большое внимание системе мониторинга. Мы уверены, что только имея корректно работающий и надежный мониторинг, мы можем оказывать сервис на требуемом клиентами уровне качества. Во время работы над первым из облачных продуктов компании – облачным хранилищем Webzilla Instant Files – мы приступили к построению системы мониторинга еще до того, как начали строить сам продукт, продумали мониторинг для каждой функции еще на этапе её планирования.



Наша система мониторинга преследует несколько целей:

• В случае сбоя, мы не должны тратить время на то, чтобы определить, что произошло. Мы должны сразу и твердо это знать.
• Чтобы предотвратить максимальное количество сбоев до момента когда они затронут клиентов мы должны контролировать метрики и события, предвещающие проблемы.
• После любого инцидента мы должны иметь полный доступ ко всем данным, необходимым для расследования его причин, даже если на момент устранения его причина не была понятна.
• Наша команда поддержки должна реагировать на сбои оперативно и верно. Единственный способ достичь этого – обеспечить сотрудников инструментом, не загружающим их ненужной информацией.

Мы работали над системой мониторинга не меньше времени, чем над функциональной частью сервиса — и мы делимся наработанным опытом.
В целом, наша система мониторинга состоит из трех основных подсистем:

Итак, у нас есть задача: пофиксить баг, производитель от которого открещивается, клиенты не замечают, а жить хочется. Есть камера, поток от неё на UDP просто адово ломается, поток на TCP работает, но постоянно рвутся коннекты (и при каждом обрыве пропадает 3-5 сек видео). Виновны в проблеме все (и камера и софт), но обе стороны утверждают что у них всё зашибись, то есть ситуация обычная: ты баг видишь? нет. А он есть.

Недавно я уже поднимал волну о баге TCP стриминга камер, но тогда я её катил исключительно на китай. А проблема куда как шире. Для себя я проблему решил, страждущим выкладываю прошивки с фиксом.

А теперь садитесь поудобнее, я поведаю вам об этом баге подробно.

Эта статья содержит те ловушки программирования, в которые я попадал сам, продолжаю попадать и возможно никогда не прекращу, а также те, в которых я находил своих товарищей.

Однако я верю в то, что их можно избежать, если знать в какие ловушки можно попасть и как из них выбираться. Возможно эта вера — очередная ловушка.

Это перевод статьи Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE Скотта Хансельмана за 30 марта.

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

Я стал замечать, что чем более опытным я становлюсь, тем больше времени у меня занимает выполнение проектов или задач. Я не теряю квалификацию от возраста, нет. Проблема в том, что я вижу слишком много способов чему-то сломаться. А количество потенциальных ошибок и просто нюансов, о которых мне известно, становится всё больше и больше.

Простой пример: раньше я просто записывал данные в файл. Теперь я думаю о правах доступа, занятии файла другим приложением, многопоточности, атомарных операциях, фреймворках, разных файловых системах, количестве файлов в директории, предсказуемых названиях временных файлов, качестве моего ГПСЧ, отключении электричества во время любой операции, адекватном API для моего кода, нормальной документации и так далее.

Это просто бомба, прямо про меня. Я тоже недавно задумывался, а не от возраста ли появляются такие проблемы, но я просто не настолько стар. Проблему создаёт огромный опыт вкупе со слишком глубоким обдумыванием задачи. Я опытнее многих, но, очевидно, не настолько опытный, чтобы не страдать от паралича анализа.

Доброго времени суток уважаемые хабравчане. На просторах интернета мне повстречался один миниатюрный и очень интересный Bash скрипт. С помощью ImageMagick он потрясающим образом обрабатывает фотографии белой учебной доски, очищая «содержимое» от всего лишнего:

#!/bin/bash
convert $1 -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 $2

До:

После:

Назрела необходимость замены медленного rdiff-backup на более шустрое решение для инкрементальных бекапов на удаленый сервер. Сперва рассматривался Rsnapshot, но причине того, что он не умеет без костылей делать бекапы именно на удаленные серверы от него отказались. Прочие аналоги нам также не подошли по тем или иным причинам. Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами. Главная цель сделать решение для инкрементального бекапа на удаленный сервер схожее с rdiff, но с использованием жестких ссылок rsync.

В этом обзоре хочу рассказать об оборудовании нашей компании для построения систем видеонаблюдения. На рынке существует множество IP камер, коммутаторов, термокожухов и другого оборудования с очень похожими характеристиками, поэтому постараюсь акцентировать внимание на отличительных особенностях. Под катом Вы можете узнать про то, как можно подключать видеокамеры цепочкой на один порт коммутатора, про умные термокожухи и про многокилометровые PoE удлинители.

Неделю назад мы с коллегами наконец выпустили в свет бесплатный курс “Переговоры в схемах” (доступен после регистрации), поэтому сегодня решили поговорить об инструментах не столько управленческих, сколько переговорных. Тем более, что вещи это более чем связанные.

После статьи «Управленческие инструменты: 4-фазный алгоритм решения проблем с людьми или «А чего ты хочешь, если ты такой хреновый менеджер?» нам писали: мол, ну так же не бывает, что со всем людьми и во всех случаях этот алгоритм работает? Это правда — этот алгоритм не очень хорошо работает, когда другой человек не видит с вами общего будущего. И/или же хочет вас банально отжать на что-то.

Один из самых полезных управленческих опытов в своей жизни я получил от руководства ремонтом собственной квартиры. На тот момент я уже 4 года работал менеджером — сначала руководил командой по тестированию Java на мобильных устройствах (мы работали с Sun), потом руководил командой в Intel. Я прочел Тома Демарко. Джоэла Спольски, прошел несколько управленческих тренингов. В общем, чувствовал себя очень крутым управленцем. Но это меня не спасло.

Управление ремонтом квартиры требует немного других навыков, тем более когда тебе противостоит опытный прораб. Мой прораб в самом начале сотрудничества применил переговорный инструмент “Формула нужды”, чем и обеспечил себе однозначную и безоговорочную победу.

Сам по себе инструмент достаточно часто применяется в переговорах с заказчиками — прежде всего, ими и применяется. Итак, как выглядит Формула нужды:

Все помнят, как появились первые действительно массовые SSD продукты. Энтузиазм, рост показателей, красивые десятки тысяч IOPS производительности. Практически идиллия.

Естественно, что для серверного (одиночные компьютеры мы не не рассматриваем) рынка это стало огромным шагом вперед — ведь магнитные носители давно стали узким местом для построения высокопроизводительного решения. Нормой считалось несколько шкафов с дисками, которые в сумме осиливали две-три тысячи IOPS, а тут такая возможность увеличить производительность в сотню и более раз с одного накопителя (по сравнению с SAS 15K).

Оптимизма было море, но в реальности оказалось все не так гладко.

Условия, которые питают креативных программистов, убивают менеджеров и маркетологов — и наоборот. Программирование — Великая Игра. Оно поглощает игрока полностью, включая и душу и тело. Если ты попался — то ты попался, и ничего уже больше не имеет значения. Когда ты в следующий раз вылезешь из своей берлоги, вполне могут обнаружиться лишние десять киллограммов, борода до колен и такое количество пустых коробок из-под пиццы вокруг, что уже, наверное, наступила весна? Но для тебя это всё не важно. Потому, что твоя программа работает, а код быстр и элегантен. Ты победил.

Окружение, которое выращивает творческих программистов, убивает менеджмент и маркетинг. И обратное тоже верно.

Программирование — это великая Игра. Она поглощает тебя целиком, тело и душу. Когда ты весь погружён в него — для тебя более ничего не существует. Когда ты выныриваешь на свет, ты можешь с удивлением обнаружить, что прибавил 50 кг, возраст твоего исподнего приближается к возрасту первоклашки, и судя по количеству коробок из-под пиццы, уже пришла весна.
Но тебе всё равно, потому что программа работает, код красив, изящен и быстр.

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

Предисловие

Одним из недостатков программных продуктов от Mozilla является их слабая ориентированность на корпоративный сегмент пользователей. К сожалению для управления инсталляциями продуктов Mozilla в крупных компаниях существует не так много инструментов. Построены они бывают на основе:

• Получения части конфигурации с веб сервера — Mozilla AutoConfig (https://developer.mozilla.org/en-US/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig)
• Интеграции части конфигурации в дистрибутив продукта (плагина для продукта)
  — CCK (https://addons.mozilla.org/en-US/firefox/addon/cck/)
• Получение части настроек из GPO GPOFirefox (https://addons.mozilla.org/ru/firefox/addon/gpo-for-firefox/)

Мне больше нравится последний подход: он позволяет гибко привязывать настройки к различным группам компьютеров и пользователей, а также все настройки можно делать из консоли групповой политики не углубляясь в написание каких-либо скриптов (в AutoConfig тоже можно формировать настройки на основе данных о пользователе, но там для этого потребуется разработка скриптов на стороне сервера). Кроме того для реализации управления из групповой политики не требуется разворачивать дополнительных отказоустойчивых серверов.
К сожалению, плагин GPOFirefox реализован только для Firefox и не имеет некоторого необходимого мне функционала, поэтому пришлось написать собственный, подходящий и для Firefox и для Thunderbird, которым я решил поделиться с сообществом.

Большинство идей, которые я почерпнул из бизнес-литературы, были бесполезны. Остальные прямо-таки вредны. Лучшими же путеводителями были интуиция и тяга к экспериментам.

Убеждение №1 бизнес-литературы сводится к тому, что целью ведения бизнеса является получение и приумножение прибыли. Некоторые книги настолько твёрдо придерживаются этой точки зрения, будто вы идиот, если с ней не согласны. Я обнаружил свои решения и результаты более идиотскими, когда купился на эту модель.

Одна из таких книг попалась мне буквально вчера, кто-то прислал мне её по почте. Сейчас эта книга лежит в мусорной корзине. В качестве картонной коробки она принесёт значительно больше пользы, чем от того, что кто-то её прочтёт.

Оптические волокно стандарт де-факто при построении магистральных сетей связи. Протяженность волоконно-оптических линий связи в России у крупных операторов связи достигает > 50 тыс.км.
Благодаря волокну мы имеем все те преимущества в связи, которых не было раньше.
Вот и попробуем рассмотреть виновника торжества — оптическое волокно.

В статье попробую написать просто о оптических волокнах, без математических выкладок и с простыми человеческими объяснениями.

Статья чисто ознакомительная, т.е. не содержит уникальных знаний, всё что будет описано может быть найдено в куче книг, однако, это не копипаст, а выжимка из «кучи» информации только лишь сути.

В деле познания SAN столкнулся с определённым препятствием — труднодоступностью базовой информации. В вопросе изучения прочих инфраструктурных продуктов, с которыми доводилось сталкиваться, проще — есть пробные версии ПО, возможность установить их на вирутальной машине, есть куча учебников, референс гайдов и блогов по теме. Cisco и Microsoft клепают очень качественные учебники, MS вдобавок худо-бедно причесал свою адскую чердачную кладовку под названием technet, даже по VMware есть книга, пусть и одна (и даже на русском языке!), причём с КПД около 100%. Уже и по самим устройствам хранения данных можно получить информацию с семинаров, маркетинговых мероприятий и документов, форумов. По сети же хранения — тишина и мёртвые с косами стоять. Я нашёл два учебника, но купить не решился. Это "Storage Area Networks For Dummies" (есть и такое, оказывается. Очень любознательные англоговорящие «чайники» в целевой аудитории, видимо) за полторы тысячи рублей и "Distributed Storage Networks: Architecture, Protocols and Management" — выглядит более надёжно, но 8200р при скидке 40%. Вместе с этой книгой Ozon рекомендует также книгу «Искусство кирпичной кладки».

Что посоветовать человеку, который решит с нуля изучить хотя бы теорию организации сети хранения данных, я не знаю. Как показала практика, даже дорогостоящие курсы могут дать на выходе ноль. Люди, применительно к SAN делятся на три категории: те, кто вообще не знает что это, кто знает, что такое явление просто есть и те, кто на вопрос «зачем в сети хранения делать две и более фабрики» смотрят с таким недоумением, будто их спросили что-то вроде «зачем квадрату четыре угла?».

Попробую восполнить пробел, которого не хватало мне — описать базу и описать просто. Рассматривать буду SAN на базе её классического протокола — Fibre Channel.

Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.

Для начала, небольшое терминологическое отступление (навеянное опять же комментарием к предыдущему посту).

Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.

Оригинал

Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.

IBM Redbook «Introduction to SAN and System Networking»

Начало

По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.

Полгода непрерывной работы. Более тысячи установок. Добавлено 95 тысяч новых строк. Удалено 84 тысячи. Было сделано 360 комитов. Вышла новая версия.
Я хочу рассказать о наиболее важных изменениях.