Как новость про +4 выходных дня уронила нам базу данных

Привет) Ниже — исключительно про команду, не про компанию в целом, у нас все-таки специфика.

Вторая линия помогла перенастроить мониторинг и автоматизацию и в этом она надежды оправдала. Но потом с выделенной второй линией получалось, что система отдельно у админов, а мониторинг и автоматизация той же системы — отдельно, у саппорта. Эффективно взаимодействовать получалось не всегда, обмен знаниями в обе стороны был достаточно ограниченным. Кроме того, были проблемы с приоритизацией, когда что-то было нужно друг от друга, ощущение единой команды тоже то было то нет. Ну и у ребят из саппорта было непонимание куда и как расти и развиваться.

В итоге через достаточно тяжелый для всех период пришли к «you build it, you run it» и по ощущениям стало сильно проще. Наверное, все проблемы, о которых я писал выше, тоже можно было бы решить как-то иначе, без смены подхода. Но пока кажется, что этот переход был удачным — летаем так уже больше двух лет и желания вернуться не возникало.

Как новость про +4 выходных дня уронила нам базу данных

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

Как новость про +4 выходных дня уронила нам базу данных

Ну и нагрузочное тестирование на 99% не отловило бы «кривой» state с незакрытыми коннекшнами на proxysql

Как новость про +4 выходных дня уронила нам базу данных

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

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

Как новость про +4 выходных дня уронила нам базу данных

Частично в облаках, частично на своём, подробно про это писал Molodoi. На своём какой-то запас тоже есть

Как новость про +4 выходных дня уронила нам базу данных

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

Как новость про +4 выходных дня уронила нам базу данных

Я не скажу сейчас с полной уверенностью, но скорее всего этот саджест появился раньше 2015 года.

Как новость про +4 выходных дня уронила нам базу данных

Простите, пожалуйста, эта ветка совсем оффтопная от темы статьи. Просто когда-то давно мы с lexxair играли в спортивное «что? где? когда?» в одной команде и я был ее капитаном.

Как новость про +4 выходных дня уронила нам базу данных

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

Как новость про +4 выходных дня уронила нам базу данных

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

Как новость про +4 выходных дня уронила нам базу данных

чОрт, я даже не подумал ее так прочитать. Десять лет прошло )

25 PHP-разработчиков, на которых можно подписаться

Paul M. Jones — один из создателей фреймворка Aura. Его посты часто попадают на phpdeveloper.org (хотя насколько фреймворк и автор популярны в англоязычном сообществе в целом — не знаю)

paul-m-jones.com/
twitter.com/pmjones
paul-m-jones.com/feed

Применяем делегирование совместно с наследованием для организации контроллеров действий

Можно сделать систему «сигналов» — в базовом

class Model_Controller 
{
...
    public function editAction()
    {
          if ($this->_hasEditAction()) {
            $this->_editActionHelper();
          } else {
            throw new Zend_Controller_Action_Exception('страница не найдена' , 404); 
         } 
    }

    protected function _hasEditAction()
    {
        return true;
    }
...
}

а в наследниках при необходимости переопределять _hasEditAction() для запрета или сам editAction() для совсем специфического поведения. Количество дублирования кода должно сильно уменьшиться.

Применяем делегирование совместно с наследованием для организации контроллеров действий

Не в основную тему поста, но так, предостережение. Если Вы блокируете в основной ветке, а снимаете блокировку только под некоторыми if'ами — можете получить проблемы.

Песочница для PHP

Под пунктом 1 имелось ввиду, что при одинаковых настройках — разрешено только echo — код

class test {
    public function method($a) 
    {
        echo $a;
    }
}
$test = new test();
$test->method('in method');

не пропускается, а по сути аналогичный код без скобок — пропускакется.

class test {
    public function method($a) 
    {
         echo $a;
    }
}
$test = new test;
$test->method('in method');

и это как-то странно на мой взгляд.

Песочница для PHP

Ага, клевая идея.
вот это пропускает:

class Pwd extends SplFileObject
{
    public function __construct()
    {
        $p = 'SplFileObject';
        $p::__construct('/etc/passwd');
    }
}

$pwd = new Pwd;
$str = $pwd->fgets();
echo $str;

Песочница для PHP

еще из возникших непоняток.

1. пропускает вызов конструктора без параметров и скобок и дальнейшие вызовы методов созданного инстанса

class test {
    public function method($a) {
		echo $a;
	}
}
$test = new test;
$test->method('in method');

2. пропускает статические вызовы через

class test {
    public static function stat() {
		echo 'static';
	}
}
$class = 'test';
$class::stat();

В совокупности с наличием ООПных системных интерфейсов типа SplFileInfo указанные выше пункты кажутся потенциально опасными, хотя сходу что-то плохое не придумывается.

Песочница для PHP

include и require пропускаются специально?

Храним ID в Cookie

а она там и есть. как часть SessionData

   try {
            $encryptedContents = $this->_encrypt(
                array(time() + $this->_keyLifetime, $contents)
            );
    } catch (Exception $exception) {
            ...
    }
    ...
    $_COOKIE[$this->_valueCookieName] = $encryptedContents;

Храним ID в Cookie

Зануда мод он: MITM это слегка другое. Зануда мод офф.

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

Если придумаете, как это обойти — пишите, будет интересно попробовать.