Сегодня еще пошатаем. Как мы все помним, тестирование - это просто один из фильтров качества Так вот есть еще одна моральная категория - это аджайл, скрам и все такое.

В чем проблема аджайл? Так же как и идеальное тестирование - его в живую никто не видел. Вот есть там инженеры за тридевять земель, у которых самые канонические процессы, а нам надо молиться и благоговеть. Мне кажется это немного неправильно. Сейчас все команды в том или ином смысле аджайл, говорить, что одни гибкие, а другие не очень, это как защищать шариковые ручки, перед гусиными перьями. Вроде бы и не зачем. Абсолютно все команды планируют и обсуждают с разной степенью успешности, работают по каким-то естественным временным интервалам, катят новые версии пореже или почаще. Гибкие - все. Но конечно по разному. Это да. Задачи разные, люди разные, история разная. Не правильно требовать одинаковости (кстати чем ярые защитники методологий часто и грешат, они хотят, чтобы все было как-то слишком одинаково).

Если честно я очень слаб в терминалогии, хотя читал много статей, книг и даже какую-то толстенную книгу по скраму, страниц на 800. Аджайл, это принцип, набор добрых советов, методология? Хм. Не знаю. Могу путать, извините заранее. Например в айкидо, в котором я к сожалению добрался всего до 4 кю и сошел с трассы, на каждом новом этапе количество техник увеличивается и составляет несколько сотен к первому дану. Потом все обратно сводится к двум базовым движениям. И далее вообще к одному у великих мастеров.

Так и в программировании. Пик знаний всяких хитрых C++-приемов у меня был на третий-пятый годы работы, потом начал забывать. Я просто научился программировать, ориентироваться в контексте. Это как езда на велосипеде - можно перестать думать про контроль кучи факторов и просто наслаждаться поездкой. На одном собеседовании меня спросили, можно ли конструктор без агрументов вызвать из конструктора с аргументами. Я ответил (если выразить мой ответ цветасто), что C++ - многогранен, аки дьявол и наверняка можно, раз вы спрашиваете, но к сожалению мне этот аспект языка не знаком. И практического смысла в вашем вопросе не вижу. Мой ответ наверное приняли, так как оффер прислали .

Сейчас, допустим, я точно не знаю чем отличается {} от do end, или что более канонично proc или labmda. Просто видел много кода и мне кажется довольно разумно употребляю то или иное. Где-то на грани ощущений чувствую, что разница есть, нагуглю если прижмет, и твердо уверен, что если в продакшен-коде знание этой разницы существенно для понимания программы, то автор кода - не прав.

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

У меня почему-то в голове темы "тестируй или погибнешь", "скрам или сдохни", "ооп без жалости и границ" - это все разные обличия одного и того же молодецкого максимализма, который с годами (а для IT у меня достаточно солидный возраст - 32 годика уже) перерастает в какие-то более спокойные формы. Перефразируя слова, которые приписывают Черчилю, скажу, что если после 5 лет работы, вы не знаете все тонкости языка, на котором работаете и не проповедуете аджайл радикального характера, у вас нет сердца, но если после 10 лет вы это все благополучно не забыли, сердца у вас все равно нет .

4 года назад я зажегся вот этим постом - Pssst... your Rails application has a secret to tell you и тут же начал отправлять метрики в HostedGraphite.

Подключил, прямо как в документации:

require 'socket'

sock = UDPSocket.new
sock.send "YOUR-API-KEY.foo 1.2\n", 0, "carbon.hostedgraphite.com", 2003

Но внезапно сайт стал скручивать ласты. Думаю вы уже догадались, хотя UDP-сообщения неблокирующие, а запросы к DNS еще как блокирующие. У хостера начались проблемы с DNS и сайт стал тормозить даже на маленькой нагрузке. Так что с хостед версией графита у нас не срослось. Увы.

Родилась у нас как-то раз шутка, что любое решение можно выставить хорошим, просто подобрав правильный термин.

Смотрите, допустим, - монолит.
- Фу-у-у.
Микросервисы!
- м-м-м, парень понимает толк в жизни.

А теперь внимание - монорейлс!
- Вау, крутяк!
И снова мужики встают, когда вы входите в пивную.

А чем монолит отличается от монорейлса? Только тем, что во втором случае придуман новый, свежий термин (вообще я не знаю насколько он используется, просто видел в одной статье). То есть это с одной стороны и шутка, а с другой и не очень шутка. Маркетинг уже очень прочно проник в инженерное дело, дажe в опен сорс. Сегодня оформлению идей, а не только содержанию, стоит уделять самое пристальное внимание.

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

Наша великолепная коллега Тоня нарисовала иллюстрацию для сегодняшней истории. Спасибо, Тоня! Три котика: .

"Преждевременный" - само слово несет в себе негативный оттенок. Мы все знаем про преждевременную оптимизацию, но я также верю, что есть преждевременный мониторинг, преждевременная архитектура, преждевременная автоматизация, преждевременное тестирование (для разнообразия речь идет о кроссбраузерном тестировании, предполжим кто-то делает MVP в 11 версиях браузеров одновременно, ) и много еще всего преждевременного.

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

Также люди неявно ожидают реакции на каждую неполадку. Допустим ночью 5 раз отправился сигнал, что сайт не доступен. Коллеги приходят на работу, видят кучу красных сообщений, и если нет никаких комментариев, они думают, что вам все по барабану. Я не ханжа, бывают ситуации, когда действительно по барабану ночные (а иногда и дневные) падения, красные тесты и так далее. Но надо помнить, что если вы понимаете и принимаете какие-то компромисы, не обязательно это будет очевидно стороннему наблюдателю.

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

Уверен, что продукт должен развиваться равномерно. Если сервис в зачаточном состоянии, то и мониторинг должен быть зачаточным, самый минимум. Так как грамотная настройка алертов и отладка процесса реагирования на инциденты могут оказаться слишком трудоемкими и избыточными, пока достаточно "чик-чик и в продакшен".

Есть народная мудрость: "знал бы где упаду, там бы костылями подпер". Если вы добавили в свой быстро растущий стартап крон-задачи, особенно чаще чем, скажем, раз в 10 минут, гарантирую, что рано или поздно они будут выполнятся дольше отведенного времени, соберутся в большую стаю и вынесут ресурсы сервера, базы или чего-нибудь еще.

Как всегда в линукс мире есть подходящее решение из коробки (источник):

$ crontab -l
10 * * * * /usr/bin/flock -w 0 /path/to/cron.lock /usr/bin/php /path/to/cron.php
# php хи-хи

Этот хак, как и многое из моего блога, гуглится за несколько минут. Но честно говоря, пару лет назад я вставлял какое-то безумие в виде создания временного файла и проверки его существования. Если почему-то вы делаете также, то попробуйте flock - будет гораздо изящнее.

Как я писал на днях, падения - не стыдно, это часть жизненного цикла любого программного продукта и сегодня хочу рассказать как продакшен падает.

Если у вас в системе есть ограниченный ресурс, то когда-нибудь он обязательно кончится. Коннекшенов будет мало, процесс убьет OOM killer, место на диске перестанет хватать, десятиминутный крон будет выполнятся полчаса и так далее. А да, сертификат вы продлить забудете, домен не оплатите, кредитку заблокируют. И хотя вроде Большой Бизнес (TM) не должен допускать таких банальных ошибок, давайте просто вспомним, что Гугл как-то на несколько минут потерял контроль над своим доменом. У Инстаграмма день был просрочен сертификат. Стек Оверфлоу вырубил умный балансер и тяжелый регексп. Там же не дураки работают? Конечно нет! Умнейшие люди! Просто когда нужно контролировать очень много параметров и процессов любая система начинает сбоить.

Под трафиком проявятся разнообразные гонки, конфликты, блокировки, какие только могут быть. Магия рейлс частенько дает сбой в нагруженных местах. Всякие constraint violation, dead locks станут обычным делом, как только нагрузка подрастет. Вообщем весело. Раскажу несколько случаев которые были у нас.

1) Бесконечный цикл. Был примерно такой же код, как в выпуске Securing an API только для генерации человеко-френдли номера класса. Естественно через пару лет метод стал сильно деградировать по перформансу, а потом и вообще отвалилься по таймауту.

before_create :generate_number
def generate_numer
  begin
    self.number = ...
  end while self.class.exists?(number: number)
end

2) Конфликт IP адресов. В Селектеле есть два вида внешних IP - Floating IP, который можно подцепить к произвольному интерфейсу, и публичная подсеть, IP из которой рекомендуют использовать для нагруженных проектов. Так вот, выдается подсеть /29, но использовать из нее можно только 5 адресов, так как первый - гейтвей. Ну у нас кто-то поставил зарезервированный IP на бокс и сайт стал очень прикольно деградировать. Он работал несколько минут, а потом переставал открываться. Все это было на фоне повышенной нагрузки и сначала мы думали, что сервера не справляются с трафиком.

3) Добавление колонок с дефалтовым значением в большую таблицу, создание индекса без CONCURRENTLY. Ну это вообще классика. Если вы не роняли продакшен тяжелой миграцией, то у вас впереди еще много интересного. Алексей Васильев написал прекрасную статью про эту тему Safe and unsafe operations for high volume PostgreSQL.

4) Мутация константных хэшей. Очень мерзкий баг. Где в инициализаторах в константу грузился yml-файл и кто-то ее случайно модифицировал в коде с помощью bang-методов (которые зло). Поэтому часть юникорнов начинала глючить. Вот здесь конечно я позавидовал языкам, в которых вшита защита от таких безобразий. К счастью дефект был наглый и очень быстро проявлялся, поэтому мы его исправили в тот же день.

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

Внеочередной не технический выпуск. Как вы может быть знаете, с 10 августа 2016 года я решил писать технический блог целый год, каждый день по рабочим днем. Мне нравится такой формат, он заставляет под другим углом смотреть на работу, перепроверить знания, да и просто тренирует заниматься чем-то регулярно. Я уверен у каждого технического человека есть много, что рассказать, но часто это будет понятно только коллегам. Рассказывать короткие истори об IT, интересные широкому кругу людей - достаточно сложно. И я чувствую, что иногда справляюсь, а иногда нет.

Так вот кризис. Это уже второй кризис. Первый я проскочил незаметно для аудитории - заранее заготовил 10 статей с картинками и полторы недели не писал ничего. Сейчас второй. Посильнее, на 7 баллов из 10. Картинки не рисую, так как их нужно принести на работу, отсканивать и ломает вот это все делать. Хотя с картинками внешний вид конечно веселей, но пока увы. К счастью в моем внутреннем соглашении нет пункта насчет этого, ничего не нарушаю, товарищ внутренний майор.

Немного предыстории. Готовился к перфомансу около года, собирал темы. Набрал больше 300 тезисов, начал писать. 250 почти сразу же выкинул, дичь какая-то или не понятно вообще к чему я их записал. Где-то каждый третий-пятый пост идет под нож, по той же причине. Остальное, выстраданное и выплаканное, попадает в очередной выпуск. Конечно я не жалуюсь и не ною (хотя, жалуюсь и ною на самом деле), но духовная практика и не может быть простой, энтузиазма обычно хватает максимум на несколько недель, а дальше обыденная, рутинная деятельность, которая впрочем довольно приятна и плодотоворна, если относиться философски.

Но думаю прорвусь, 10 месяцев осталось, фигли там. Держусь, настроение, ммм..., хорошее! Удачи мне .

Есть одна тема, которую я прямо чувствую, что не принято обсуждать - это падения продакшена. Причем, хотя не падают только те проекты, которыми никто не пользуется или которые еще не написаны (идеальный софт бывает только в голове), но почему-то все равно стыдно.

99% падений, чего уж там скрывать, вызваны именно ошибками инженеров, человеческим фактором, незнанием каких-то тонкостей и особенностей системы и так далее. Скорее всего поэтому тема падений неудобная, так как люди считают, что признание своих ошибок подрывает их профессионализм. Но я с таким подходом категорически не согласен. Как программные дефекты - это часть процесса управления разработкой, так и разнообразные нештатные ситуации - это часть процесса управления эксплуатации систем. Бизнес интегрити и все дела.

Чтобы еще более успокоить, приведу цитату из книги Питера Друкера "Эффективный управляющий" (вообще книга хороша, хочется процититировать ее почти целиком, выделение жирным - мое):

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

Так что падения - это нормально, значит у вас есть живой сервис. Падение под трафиком - это вообще прекрасно, значит у вас есть трафик. Падение из-за неправильных действий - чудесно, значит вы что-то делаете. И так далее .

Контекст важен. И чем старше я становлюсь, тем отчетливее это понимаю. Вот например, смотрите: "Руби - гамно". В зависимости от окружения и от автора этого высказывания - это может быть глупостью, бахвальством или глубоким пониманием конкретной ситуации и задачи (выраженное тем не менее достаточно вульгарно).

В жизни я относительно легко разбираюсь в контексте инженеров, и что они вкладывает в те или иные фразы. А вот в интернете мне гораздо сложнее. Пожалуй интернет использую просто как большой справочник, я очень мало здесь общаюсь. Остро не хватает пометок "умный, глубокие знания A, B и C, любит тонкий троллинг и неоднозначные высказывания" или "глуповат, нет чувства юмора, заносчив, обходить стороной".

Мне кажется, что в ЖЖ такие пометки есть, можно создавать каждому комментару персональный контект и его историю. Вроде Лебедев такими пользуется, при выращивании своей аудиторию. Если есть цель именно ухаживать за деревом комментариев, наверное это даже удобно...

Вообщем все сложно.

Если вы любите бутстрап, а если вы программируете внутренние сервисы и админки, то вы обязаны любить бутстрап, вам также понравятся вот эти бесплатные шаблоны писем от мейлгана. С помощью них вы сможете добиться не только прекрасного внешнего вида сайта (меня правда уже подташнивает от чистого бутстрапа, но я не знаю более быстрого и простого способа набросать несколько интерфейсов), но и будете отправлять очаровательные письма.

Подкючаете гем premailer-rails, кидаете styles.css прямо в public, копируете любой из трех html-шаблонов во вьюху письма, исправляя ссылку к стилям прямо на http://cdn.example.com/styles.css, что это значит не разбирался, но именно так работает гем, и AwesomeMailer.foobar.deliver. Вуаля, прекрасно сверстанное письмо (кстати здесь без иронии, письма действительно выглядят очень прилично) оказывается у адресатов.

Можно конечно отправить и мейлчимповский шаблон через мендрил, но мне кажется с шаблонами мейлгана получится быстрее.