Мы в Perfect Solutions на прошлой неделе написали сотое по счету API. За все это время, ценой граблей, костылей, велосипедов и рефакторинга, мы поняли, что выработали отличную стратегию «как писать API и прекратить боль и страдание».

Этот пост о версировании, поддержке, багфиксинге и полном цикле жизни API.

Под катом нет фото с большим трафиком, нет серебрянных пуль, тут даже нет картинки для привлечения внимания — только полезная выжимка нашего опыта. Под катом методология, выработанная на реальном опыте разработки, набитых шишках и сломанных грабляхъ.

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

• «Нам важен готовый продукт — плевать на плохой код»
• «Нам важен поддерживаемый продукт — пусть это и будет долго»

Это вечный спор между «говнокодом» и «скоростью разработки», менеджерами и разработчиками. Ошибаются обе стороны. Это два конца одной палки. На этой палке я бы написал красными буквами «ошибки руководителя разработки». Кому интересная эта тема — добро пожаловать под кат. А еще под катом много букв об архитектуре ПО, микросервисах и здравом смысле.

В статье речь будет идти о systemd, который вошел в Debian 8 jessie. Я пишу о Debian, потому что пользуюсь именно им. Пишу о systemd не потому что его фанат, но некоторые вещи меня действительно радуют.

Так почему же больше не нужны supervisord и forever?

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

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

Мы привыкли делить мир вокруг нас напополам: на добро и зло, на быстро и медленно, на размерено и взмыленно. Так же разделяется экономика: на плановую и рыночную. Так же разделяется программирование: на императивное и деклоративное. И так же разделяется управление: на планое и ситуационное…

Есть сервисы, защищающие нас от DDoS атак. Они работают по принципу прокси: в DNS прописывается их IP, они фильтруют трафик и проксируют на ваш сервер. Все они настоятельно рекомендуют прятать свой IP и в публичном доступе давать только IP прокси-защитника. Вполне здравый подход, достаточный для успешной защиты. А я расскажу на чем можно проколоться и как от этого защитится.

Введение

Это статья для тех кто хотел чуть побольше узнать о Linux, но либо стеснялся спросить, либо пока не задумался. Начнем мы с самого большого разочарования — операционной системы Linux нет.

В рамках одного из моих проектов, я провел небольшое исследование — как медленный интерфейс влияет на поведение пользователя?

Некоторые выводы были весьма очевидными, некоторые следуют из очевидных, а некоторые весьма неожиданны. Хочу поделится полученным опытом от удачного эксперимента с Хабрасообществом.

Эксперимент проводился довольно просто, по принципу A/B тестирования. Аудитория A работала с сервисом «быстро», так как они и работает. А у аудитории B при отдаче каждой страницы был сделан sleep на 700 миллисекунд.

В сырцах разных авторов видел я разные варианты вечного цикла. Чаще всего мне встречались следующие:

while (true) {
...
}

и

for (;;) {
...
}

Поскольку каждый защищал “свой вечный цикл” как родного, я решил разобраться. Кто же пишет более оптимальный код.

Мы часто экспериментируем с архитектурой, кодом, производительностью. Постоянно добавляем новый функционал. Мы постепенно обвязываем Yii своей “архитектурной” прослойкой — шардинг, работа с временно недоступными данными, разнообразные кеши и многое другое. Да, плод нашей работы, когда он будет заврешен, пойдет в Open Source.

Задача применяемой у нас Непрерывной Интеграции (Continuous Integration, CI) — не тестирование. Задача CI — обезопасится от разрушительных изменений в следствие рефакторинга, добавления нового функционала, изменений архитектуры. Также мы защищаемся от “плохого кода”, часто повторяющихся багов, “кривых” merge.

Для своего CI мы используем Jenkins под Debian. Время на развертку CI я затратил 12 часов — до полностью рабочего состояния. На поддержку CI я не трачу ни минуты в день — я не пишу тесты на каждую мелочь, не практикую TDD. Тем не менее, CI работает и спасает нас от глупых ошибок.

“Давайте будем внимательней”/”Давайте не делать ошибок” — взывал я к разработчикам, но это помогало лишь временно и то не на все 100%. Людям свойственно ошибаться, забывать, совершать оплошности. Нет, я не изобрел “серебряную пулю” для web-проектов и даже маленьку пульку для Yii — я придумал как стабилизировать свое приложение. Ваше приложение отличается от моего и мои методы у Вас могут не работать, да и не должны — я же делал их не для Вашего приложения, если мои методы работаю у Вас — примите это как чудо или как везение. Зато идея такого CI будет работать везде. Всего лишь идея.

 

Совсем недавно на мой сервер с git репозиторием началась атака по подбору паролей к gitlab и ключей к ssh. Намерения злоумышлеников понятны — вытащить исходный код проприетарного приложения хранящегося в git.

Мне не совсем понятны попытки подбора ssh-ключей, т.к. проблематично подобрать RSA-ключ (это займет десятки лет), но я всё же сделал некоторые ограничения для того что бы не так сильно «загаживались» логи.

Кому интересно как защитить gitolite и gitlab (работает за nginx) от подбора паролей — добро пожаловать под кат.

Совсем недавно у меня появилась задача защитить web-приложение полностью построенное на ajax от CSRF-атак.

Каков же механизм такой атаки? Суть заключается в выполнении запроса с другого сайта под авторизационными данными пользователя. Например, у нас есть действие удаления своего аккаунта example.com/login/dropme. Если защиты от CSRF атаки нет, мы можем на нужном нам сайте разместить тег:

<img src="http://example.com/login/dropme">

Сразу после того как пользователь зайдет на приготовленную нами страницу и подгрузит содержимое img, его аккаунт на example.com будет удален. О защите от этого я расскажу под катом.