​​Как внедрять изменения и не остаться у разбитого корыта

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

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

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

Поэтому мы делаем так: планируем и разбиваем на части внедрение, выполняем замеры времени и составляем временной график. Это позволяет оценить сколько времени нам понадобится на то, чтобы все сделать как надо.

Затем берем и планируем обратный процесс: т.е. полный откат всех внесенных изменений от конечного состояния к начальному. И составляем второй временной график. Это сразу поможет понять сколько времени понадобится чтобы вернуть все как было, даже если откатываться придется с самого-самого последнего этапа.

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

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

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

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

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

Это может усложнить и удлинить процесс, но позволит реализовать его частями. Теперь, если что-то пошло не так – возвращаемся к очередной точке фиксации.

Также это позволяет выполнять внедрение в рабочем режиме, без необходимости выхода в ночь, на выходные и т.д. и т.п. Да, дольше, но тише едешь – дальше будешь. Работы в сжатом технологическом окне не располагают к вдумчивому погружению в рабочий процесс.

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

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

А каких методов планирования придерживаетесь вы? Спринт или спортивная ходьба? Планируете ли откаты?

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

​​EasyPlay – теперь и игры

Денис Давыдов – автор проекта EasyAstra, направленного прежде всего на упрощение работы с Astra 1.7 SE, по просьбам пользователей запустил новый проект – EasyPlay.

ЕаsyPlay переносит на платформу Astra 1.7 SE классические игры, такие как Quake, Doom или Герои. При этом вам не нужно что-то настраивать, все игры упакованы в DEB-пакеты, просто скачать и установить.

Как говорит сам автор, проект развивается в свободное время, что-то собирается нативно, что-то грамотно упаковывается в Wine.

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

Игр пока не много, полный список вы можете посмотреть здесь: https://play.easyastra.ru

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

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

​​Что такое Umask в Linux и для чего он нужен

Umask в Linux – это параметр операционной системы, который определяет набор прав доступа присваиваемый новым (создаваемым) файлам и папкам.

Как мы помним, полные права для файлов описываются как:

rw- rw– rw- или 110 110 110 или 666

Для папок:

rwx rwx rwx или 111 111 111 или 777

Напомним, что x для директорий – это не выполнение, а доступ к файлам директории и их атрибутам, потому как r дает возможность только получить список файлов директории.

Что касается файлов, то признак «исполняемый» устанавливается по необходимости создающей программой и по умолчанию в расчет не берется.

Как работает Umask? Это маска и она имеет обратное, по сравнению с правами значение, т.е. установленный бит маски обозначает запрет на действие.

Допустим мы хотим по умолчанию устанавливать права файлов (владелец, группа, прочие):

rw- rw- r--

и директорий:

rwx rwx r-x

Так как для файлов мы игнорируем бит x, то получаем одинаковый двоичный набор:

000 000 010 или 002

Хотя снова вспоминаем, что на самом деле в правах не три, а четыре октета, поэтому правильно будет не 002, а 0002. Хотя первый ноль можно отбрасывать для простоты.

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

Для root применяется по умолчанию маска 0022, т.е.:

000 010 010 или rw- r-- r-- для файлов и rwx r-x r-x для директорий.

👆 В Debian обычный пользователь, также как и root имеет маску 0022.

Узнать текущую маску можно командой:

umask

А добавив к ней значение маски можно установить новое значение, например:

umask 077

Здесь мы подходим к еще одному вопросу – правильному расчёту маски, многие пытаются оперировать восьмеричными цифрами просто вычитая от 666 или 777 значение маски. Но это неверно, хотя во многих случаях дает верный результат.

Но если исходить из этого допущения, то маска 066 для файлов будет равна маске 077. Но это не так, если перевести маску в двоичный вид, то мы увидим, что 066 это:

000 110 110

Т.е. разрешает устанавливать исполняемый бит группе и прочим. А 077:

000 111 111

Полностью сбрасывает права для всех, кроме владельца.

Возможно сложновато, поэтому umask можно передавать параметры желаемого набора прав явно и в более привычном виде, например, для маски 0002 можно указать:

umask ug=rwx,o=rx

А для 0022:

umask u=rwx,go=rx

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

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

​​Жизнь и приключения молодого и перспективного хостинга, серия вторая

Прислали мне сегодня ссылку про один молодой и перспективный хостинг [1], прочитав ее я маленько был в шоке. Возможно – грязная конкуренция? Возможно, если бы автором статьи был не один из учредителей данного проекта:

Всем привет, меня зовут Арсений, мне 20 лет и я СЕО компаний Aeza Group Ltd.

Сначала автор пускается в просторный рассказ как он жил раньше:

До запуска Aeza. net были различного рода мелкие конторки, которые официально никто не регистрировал, и в целом этого не требовалось, учитывая обороты и отсутствие банально собственной инфраструктуры и сотрудников

Ну тут трудно в чем-то упрекать, все так начинают, но товарищ явно лукавит, потому что конторка там была и совсем-совсем не мелкая…

Но об этом он как бы вскользь:

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

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

Итог не заставил себя долго ждать:

меня разбудили в 6 утра с криками в телеграмм, что хоста больше нет (речь про подработку, не про аезу еще), …первое что я сказал сделать, это погасить всю сеть, чтобы доступа не было ни у нас, ни у злоумышленников, но подробности этой истории можно легко найти в интернете по запросу «Взлом MskHost».

Ну нефига себе «мелкая контора» и «подработка», в свое время взлом и падение MskHost наделало много шума. Ну ладно, взломали, с кем не бывает, но взломщики были не так просты [2, 3], они поясняли свои действия тем, что хостинг не реагирует на жалобы и размешает всякую «чернуху»: кардинг, скам и прочую «грязь»:

Никто не реагировал, закрывал глаза, посылал на три буквы нас. Мы вместе с ведущими пентестерами СНГ вынуждены нанести удар по инфраструктуре этого хостинг-проекта и очистить Рунет от такого масштабного хостера черни.

Взломщики разместили в сети информацию из которой следовало, что топ заказчиков хостинга как раз таки составляли скамеры и т.п.

Реакция владельцев (владельца) хостинга была ожидаемой: он заявил, что результатом произошедшего является конкуренция — «грязная, нечестная, но конкуренция». И объявил о «банкротстве».

По факту произошел односторонний отказ от обязательств, так как связанное с MskHost юрлицо процедуру банкротства не проходило.

Ладно, история продолжается:

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

Как вы догадались это была Aeza и дела у нее вроде как даже пошли, но тут нашего бизнесмена и учредителя снова заносит куда-то не туда:

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

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

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

Здесь же похоже на очередное «головокружение от успехов», денежка пошла – живем и ни в чем себе не отказываем.

Продолжение следует…

​​Жизнь и приключения молодого и перспективного хостинга, серия вторая. Продолжение.

Продолжаем читать и анализировать откровения одного из учредителей молодого и перспективного хостинга:

Всем привет, меня зовут Арсений, мне 20 лет и я СЕО компаний Aeza Group Ltd.

Прошлая наша заметка закончилась тем, что, основав Аезу герой нашего рассказа впал в продолжительную «депрессию» и год непонятно чем занимался, точнее занимался всем чем угодно, но только не хостингом.

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

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

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

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

Но тут наш герой вышел из своей "депрессии" и сильно удивился:

И каким образом за этот год моего отсутствия аеза выросла — я не знаю, я могу лишь поблагодарить всю нашу команду, за вашу самостоятельность.

И на него снизошло озарение:

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

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

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

Т.е., говоря понятным языком – соучредителя просто выбросили из проекта на мороз. Операция не прошла гладко, а сопровождалась масштабными сбоями, которые потом были компенсированы, и поддержка пояснила происходящее как:

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

Сам же автор описывает это следующим образом:

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

А дальше все начало цвести и пахнуть, добро победило зло и т.д. и т.п.

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

Только вот расти начали куда-то не туда. Начиная с «хитрых» финансовых манипуляций с овердрафтом, который способен просто выставить клиента на деньги в разы, превышающие стоимость тарифа, при этом условия предоставления овердрафта нигде не указаны [4].

Дальше-больше, даем слово компании Имиджмарк, которые занимались отражением хакерской атаки на Битрикс [5]:

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

Ничего не напоминает?

Вместо этого мы заблокировали весь трафик с их серверов, и атаки сразу же прекратились.

Похоже aeza под управлением молодого и перспективного менеджера решила идти по стопам MskHost.

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