DevOps в Enterprise и финансах. Есть ли жизнь на Марсе

    Артём Каличкин (ЦФТ)

    Артем Каличкин (ЦФТ)


    Меня зовут Артем Каличкин, я работаю в компании «Центр Финансовых Технологий», которая занимает лидирующие позиции по производству и разработке программного обеспечения для банковского и финансового сектора. Я занимаю должность директора по сопровождению эксплуатации.

    Возможно ли использование практик и подходов DevOps, CD в корпоративной среде? Какие особенности? SPARC + Unix (Solaris)? Вертикальное масштабирование и как следствие — разная конфигурация в бою и на стейдже. Об этом и поговорим.


    В принципе, в структуре производства компании есть две части:

    • на одной чаше весов у нас разработка банковского программного обеспечения. Это автоматизация деятельности банка, управление счетами, в том числе управление клиентскими счетами, core banking. Это некая коробка, которая кастомизируется под банк и устанавливается на мощностях банка;
    • на другой чаше весов у нас пул так называемых процессинговых сервисов. Что это такое? Это разработанные нами продукты для конечного потребителя, для физика. Какие известные здесь можно привести примеры:

      • Транспортная карта у нас во многих регионах, появилась недавно в Московской области под названием «Стрелка», мы являемся техническим провайдером этого решения.
      • Федеральная система «Город» для приема платежей — от коммунальных до погашения кредитов.
      • Дистанционное банковское обслуживание «Фактура» — сервис, над которым я непосредственно работаю.
      • «Золотая корона» — денежные переводы, третий в мире сервис по обороту.
      • Сервисы, которые крутятся вокруг продуктов карт «MasterCard», которые можно получить в торговой сети без открытия банковского счета. Наверное, самый известный из них, это «Кукуруза» копании Евросеть. Это тоже наш продукт, наше решение, и все, что на нем крутится.

    Зачем я про все это рассказываю? Смысл этих продуктов, их особенностей с точки зрения эксплуатации и сопровождения заключается в том, что мы обеспечиваем для этих процессинговых сервисов полный цикл. Мы их разрабатываем — придумываем идею, разрабатываем, мы же у себя на своих мощностях, на своих дата-центрах их размещаем и, собственно, обеспечиваем всю операционную эксплуатацию и сопровождение.

    Как выглядит эта штука, которую я назвал эксплуатацией и сопровождением в таком финансовом секторе? Она выглядит вот так в реальности:



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

    Какие у этой картинки тактико-технические характеристики? В качестве оборудования, которое размещено в наших дата-центрах, используются Oracle’вые сервера, сервера на архитектуре SPARC, т.е. не X86, это отдельная SPARC’овая архитектура, операционная система Solaris. Поскольку это финансовый сервис, к счастью, физики пользуются этими сервисами в режиме 24х7, поэтому и аналогичные требования к uptime и к работе системы — это 24х7, 4 девятки, ну, круто было, если было бы 5. Такие требования. При этом особенностью еще является кое-что, не относящееся к контексту данной конференции, — у нас очень много, практически 90%, бизнес-логики написано на Oracle. Когда я говорю, что написано на Oracle, это означает, что да, это пакеты на PL/SQL коде, которые лежат в СУБД Oracle. Таким образом реализовано примерно 90% бизнес-логики. Соответственно, какие-то изыски связаны с простым масштабированием. При этом у нас все эти огромные сервера — вертикальные, а не горизонтальные никак. Это все наша особенность.

    Как я сказал уже, 24х7, 4 девятки, код на PL/SLQ… И у нас очень узкое звено — мы не можем обновлять систему, не делая downtime, т.е. мы должны опустить систему, произвести накатом обновление, после этого ее поднять. В России мы во всех часовых поясах работаем и делаем так: мы выбрали окно, в которое минимальное количество клиентских транзакций проходит, и в это окно мы downtime’мим систему. Это окно — это с часу до 2-х часов ночи по новосибирскому времени. В это время у нас админы по-настоящему в ночь выходят и катят обновление на бой.

    Как они это делали? Это портянка такая в word’вом документе (потом мы на confluence перешли, там тоже отдельные особенности были), в котором инструкциями написано, что надо сделать: забэкапить, скопировать сюда, сюда перекопировать, залить, зайти в config-файл, выставить такие-то параметры, катануть на базу, проверить инвалидацию пакетов, что ее нет, что все хорошо. Т.е. это ручная инструкция. Дистрибутивы передаются через файловую шару, т.е. грубо говоря, мы выкладываем «web_new_new», чтобы там точно new забрали, но админ среди ночи берет из «web new_», который разработчик забыл удалить, когда выкачивали… У него были какие-то проблемы с доработкой, с выкаткой… Значит, в итоге выкатывается какая-то не та, предпромежуточная версия. Т.е. понятно, что при таком цикле обновления боевой системы бездна ошибок неизбежна.

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

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

    Я позволю себе небольшой эксперимент. У всех наверняка есть карты «MasterCard», «Visa» и т.п. Представьте, что у всех у вас карточка выдана банком «ГазМясБанк», вы являетесь клиентом «ГазМясБанка». И, значит, вы из прессы и из анонса, который вам прилетает на почту, узнаете, что банк «ГазМясБанк» недавно был куплен достаточно молодой агрессивной финансовой группой «АйДаПарни», и банк был переименован в «АйДаБанк». После этого, где-то через месяц, вы получаете такое по-хипстерски открытое дружелюбное письмо от банка, адресованное вам. Там написано буквально следующее: «Привет, Серега! Мы знаем, что ты часто рубишься в игры по ночам и любишь совершать различные платежные транзакции после 2-х часов ночи. Мы прекрасно понимаем, как это стремно — оказаться в ситуации, когда ты не можешь совершить срочно платеж необходимый, очень напряженный или в очень пикантный момент. Поэтому мы решили пойти тебе навстречу, быть в духе времени, короче, мы все наши процессинговые сервера, все сервера с данными о карточных продуктах в облака на «Амазон» для повышения доступности операционной выносим». Ваши действия на следующий день после этого письма? Кто не заберет свои деньги из этого банка? А кто заберет свои деньги из этого банка? Я не знаю, почему есть те, кто не заберет. Видимо, в качестве эксперимента.

    Кстати, мы выложили в открытый доступ видеозаписи с конференций по эксплуатации и devops RootConf 2015 и 2016. Вот соответствующие листы в нашем аккаунте — 2015 и 2016 в нашем аккаунте на YouTube.

    Смысл в том: мы не должны забывать, что работая в финансах, работая в энтерпрайзе, мы несем прямую ответственность за ваши персональные данные, за вашу банковскую тайну не просто перед вами, клиентами, что, безусловно, самое важное, но мы несем ответственность и перед Центробанком, и перед регуляторами, перед соответствующими международными организациями. Это не просто наше желание быть вам угодными, это просто необходимость. Мы обязаны соблюдать определенные нормы и требования, их несоблюдение грозит отзывом лицензии. Условно, у ЦБ есть требования завершенности платежа — если клиент отдал тебе деньги, ты обязан выполнить его поручение по дальнейшему процессированию этой денежной суммы.



    Соответственно, ответ на этот вопрос не очевиден, т.е. мы не можем взять и просто стать такими, как парни из «АйДаБанка», у нас лицензию отзовут просто сразу, если мы станем вот такими:



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

    Этот синдром заключается в том, что «мы же все равно не сможем полноценно DevOps использовать, чего нам пытаться?» Или «ну, чего мы один продукт начнем выносить по-другому, и чего толку, все остальное же по портянке будем выносить, конфигурировать все равно, грубо говоря, вы сейчас не сможете». Т.е. огромное количество возражений из принципа «все или ничего». Мне действительно все это очень напомнило один из постулатов по обучению Skrum’у, когда практически любой Skrum тренер доказывает аудитории, что вы либо полностью следуете Skrum’у, либо у вас Skrum — 0. Но в отношении Skrum’а это в какой-то мере, может, обосновано в силу глубокой детерминированности этого процесса, сильной взаимосвязи всех элементов. Но в целом, во всем остальном я не согласен с этим подходом. Ничто не является истиной. Ничто не является 100% ответом на наши вопросы. Из всего нужно вычленять крупицы здравого смысла и внедрять именно их. Я пришел к такому мнению, и мне удалось в нем убедить коллег, что серебряная пуля существует.



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

    Ок, этот этап сопротивления я прошел, удалось убедить и IT-департамент, и наших коллег в том, что мы сможем пройти этим путем. Но возникает следующий вопрос: а зачем? 20 лет так живем, занимаем лидирующие позиции на рынке, все ж работает и так, клиенты пользуются сервисами, зачем нам твои изменения? Зачем нам что-то менять в нашей жизни? Тут я позволю личные размышления на достаточно глобальную тему. Согласен на помидоры и на все остальное. Но я, анализируя различные наши кейсы, пришел к такому видению.



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

    Было, я считаю, до тех пор, пока в разработке программного обеспечения все-таки не стал преобладать дух стартапов, не стал преобладать дух бережливого производства. Потому что техники и подходы бережливого производства нам позволяют перевести этот вопрос, эту дилемму в другую плоскость, добавив одно измерение. Что это за измерение? Это наполненность фичами вашего продукта. И, собственно, позволяют говорить на другом языке.

    Если мы говорим про бережливое производство, про бережливый подход к запуску продуктов, про стартапы, то не возникает вопроса выбора двух из трех. Они берут, делают все три и спрашивают: «Что еще сделать надо? Давайте, у нас руки горят, мы еще хотим. Что еще?».

    За счет чего? Конечно, за счет того, что программное обеспечение — это не самолет, это не тяжелое машиностроение. Мы, производя программное обеспечение, можем и должны поднимать в воздух недостроенные самолеты, мы должны поднимать MVP. Нынче коллеги вернулись с конференции из Нью-Йорка, говорят, там новый тренд — делайте MVP от MVP. В принципе, тоже обоснованный подход. И это все нам позволяет уйти от этой дилеммы. А это значит, что если мы от нее не уйдем, то конкуренты наши от нее уйдут, и обскачут нас совершенно легко. Мы пока сидим, умно по старинке выносимся и говорим: «Ну, нормально же, работает». Появляются молодые компании, которые не знают о том, что есть такая дилемма, они действуют в духе лин-стартапа (Lean Startup) и делают все три условия и нас на каком-то сегменте обходят. Но не на всех. Но постепенно обойдут на всех. То, что мы не можем сделать сегодня, завтра наши конкуренты сделают. Это, с моей точки зрения, основной ответ на вопрос, зачем нам меняться? Мы просто не имеем права, если мы хотим оставаться на рынке и продолжать предлагать качественные проверенные временем финансовые услуги, мы обязаны меняться в сторону технологий бережливого производства, в сторону технологий DevOps, а про Agile я, вообще, не говорю.



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

    Вкратце пробегусь по небольшому набору проблем, с которыми мы столкнулись.



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

    Соответственно, дальше Solaris, причем не просто Solaris, а Solaris 10-ый, т.е. актуальная версия 11.2, последняя, а у нас Solaris 10-ый. Под него собрать продукты — это отдельный ад и боль, т.е. все эти зависимости, все это докачивать, из бинарников собирать, компилировать. Я не знаю, по-моему, месяц chef компилировали под Solaris свой. Это было очень долго.

    Третий вопрос. У нас долго был вопрос по поводу бинарщины, т.е. была очень важная задача — мы должны были обязательно уйти от передачи дистрибутива через файловую шару, потому что это бездонный источник ошибок. Всегда кто-то какие-то артефакты из этой шары недочистил, где-то косякнул, неправильно назвал директорию, какие бы конвеншны не принимали, косяки будут. Поэтому мне принципиально необходимо было, чтобы мы от файловой шары ушли. Мы в качестве решения выбрали все-таки пакетный менеджер. Пакетный менеджер мы взяли IPS форк, версию IPS. Он, как бы, в 11-ом Solaris’е есть, в 10-ый мы делали. У них проект кроссплатформенного IPS, мы от него делали под себя форк и собирали под 10-ый Solaris. Тоже была отдельная свистопляска. Но, тем не менее, дистрибутивы мы передаем через IPS, через пакетный менеджер. Этот путь мы прошли, и мы им довольны.

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

    Заметили такую особенность — Ruby медленно работает на SPARC архитектуре. Т.е. что мы с ним не делали, как мы его не крутили, сравнительно с x86… В принципе, в священных Интернетах эта информация находит подтверждение. Действительно, получается, что в силу архитектурной особенности… Там же как — там большое количество слабых процессоров, но их очень много. И на этой истории код работает значительно медленнее, чем под x86 платформу.

    Обновления без остановки на текущий момент мы добились. Я считаю, что во многом у нас очень большой прогресс, но не во всем. Я расскажу подробнее об этом. Если нам нужен на сервере новый apache, мы создаем заявку, о том, что «разверните нам новый apache». Мы сами можем без проблем зайти и развернуть, но нельзя. Мы создаем заявку: «Разверните нам новый инстанс apache». Мы неделю ждем, когда у админов появится время, потом они заходят и заводят нам apache, еще неделю там заводят пользователей, потому что забыли завести их в тот момент, когда apache поднимали, и вот, о счастье, мы получаем apache. У нас недавно ребята в Томске сидели и бесились: «Почему?...». Мы не можем объяснить логически, почему нам apache поднимали две недели, мы вам тоже не можем объяснить. И, к сожалению, это пока для меня остается болью. От этого тоже хочется в перспективе уйти, но пока окружение нам готовят вручную. Но смысл в том, что у нас вертикальное масштабирование, нет горизонтального, как такового, мы только-только подступаемся. И поэтому мы не плодим ноды каждый день, у нас нет задачи на 50 новых нод катануть типовое окружение, ее просто нет, поэтому это не так болезненно пока для нас.

    Безусловно, я чуть позже остановлюсь, когда буду рассматривать вопрос команды, именные войны. Они начались: «Вот это мое, вот это твое». Мы в какой-то момент времени этапа проекта докатились до двух, как я их называю, двух братьев уродов-близнецов — Div DevOps и Ops DevOps. У нас создавалось два параллельных конвейера, параллельных стека, параллельных решения. Ops, обидевшись на всех, написал свой Ops DevOps. Dev сказал: «Да чего их ждать, мы сами написали свой Dev DevOps». Такая картина.

    Приходилось это как-то перехватывать, улаживать. Как мы это решили, расскажу позже. Я и на конференции не услышал какого-то очевидного понятного toolchain’а от начала до конца, что использовать. Наверное, не существует этого ответа. Мы пока для себя не определились, т.е. у нас действительно есть некие вопросы, потому что chef энтерпрайзный нам не подходит, puppet, как вариант. У нас часть продуктов на puppet, puppet мы деплоим. Часть продуктов на chef. Это в целом, часть того треша, на который мы натолкнулись, причем, мы натолкнулись, не ожидая этого, соответственно, сталкиваясь с этим, не знаем, что делать, а уважаемое сообщество спрашивать бесполезно, потому что ответ будет один: «Не будьте дебилами, уходите с Solaris’а на что-нибудь нормальное». Нам не подходит такое решение, поэтому мы в этом смысле в некой изоляции находились и «плакали, кололись, но продолжали есть кактус». Это картина мира.



    Как это происходило. В целом мы проект официально стартанули в 2013 году. Мы поставили для себя следующие ключевые задачи, цели. Для нас важно было научиться обновлять днем все, что можно обновлять днем. Т.е. обновлять без простоя, обновлять без downtime. Потому что ночные обновления — это мука, это большие социальные проблемы в коллективе, потому что народ перегревается. Когда вам нужно админу задеплоить патч днем из-за того, что разработчик-косячник что-то накосячил — это полбеды, а когда админу нужно ночью снова выходить и катить этот патч, тут эта грызня, DevOps’овское перекидывание какашек друг в сторону друга достигает неких ультрамасштабов ненависти, просто черной ненависти. Соответственно, минимизировать ночные обновления — это одна из очень важных задач была.

    Дальше задача была — к ночным работам все-таки подходить (к дневным тоже, но в-первую очередь, к ночным, потому что там не все доступны), полностью понимая, что мы будем делать, что у нас входит в релиз, в набор релизных работ. А почему? Потому что не редки были случаи, когда, первым этапом, еще до DevOps, я ITIL внедрял, было в части релиз менеджмента. Я говорю: «Ребята, давайте перед ночными работами разработчики и эксплуатация будут собираться вместе и обсуждать, что будут ночью делать, а не просто разработчики молча передали инструкцию, на все вопросы — там же все написано, вы что дебилы, что ли? А те — ну, они инструкцию писать не умеют, им-то все понятно, нам, вообще, ничего не понятно». И разошлись в разные стороны.

    Для начала мы научились собираться вместе и обсуждать, что будет ночью происходить. Почему это важно? Потому что все так, скорее всего, никогда не пойдет. Скорее всего, что-нибудь ночью пойдет не так. А для того, чтобы понять, какой предел допустимости, когда все-таки принимаем решение об откате всех работы, допустимы ли эти ошибки, которые в логах посыпались после наката. Они могут быть допустимыми, могут — нет, для этого нужно понимать, что мы катим. Поэтому мне это было критично важно.

    И идеально знать боевую ситуацию. Достаточно разветвленная, сложная на уровне логики схема боевого деплоя… Большое количество транспортных услуг (я называю их транспортными), наша определенная специфика java модулей, огромное количество отвечающих за разные нюансы и вопросы… И постоянно вносятся какие-то изменения, корректировки, правки параметров, и далеко не всегда мы имеем в момент инцидента четкое понимание, что эта вся огромная наша боевая инфраструктура сейчас из себя представляет. Это необходимо было обязательно обеспечить. И до DevOps я действительно предпринимал попытки внедрить CMDB ITIL’овский, но к процессу управления конфигурацией мы успешно внедрили и, в принципе, свели на ноль количество инцидентов, связанных с некорректно выполненными изменениями, и не проверенными потом, CMDB не понадобился.

    Это, конечно, бюрократическая муть, когда вы должны выполнить работу, потом куда-то сбегать и еще там отразить, какие вы параметры на apache настроили. Тут надо от обратного. Я, в общем-то, из-за этого за DevOps в свое время и зацепился. Ко мне приехал коллега с HighLoad и говорит: «Слушай, там про систему управления конфигурацией какую-то рассказывают, это на твой DevOps не похоже, нет?». Я читаю про Chef и думаю: это что-то не то, мне-то нужно контролировать свою инфраструктуру, а они ее меняют рецептами. Но потом пришло понимание, что я не хочу контролировать, я хочу управляемо изменять инфраструктуру, такая моя задача. Соответственно, я хочу идеально знать боевую ситуацию.



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

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

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



    Что мы имеем на сегодняшний день? Чего за это время мы достигли?

    • Мы действительно обеспечили 100% единообразие схем развертывания в разработческой среде и в продакшене, и поскольку мы теперь меняем эту схему развертывания рецептами, она автоматически поддерживается. Т.е. рецепты пишем и накатываем их у себя в разработческой среде, дальше они идут в бой, там накатываем, получается естественная синхронизация.
    • Для наших Java-приложений мы практически полностью сделали конвейер развертывания — от производственных схем до боевой наливки в продакшене.
    • Для веб-приложений сейчас еще в процессе, частично готово, частично не готово, но уже на подходе. Я бы поставил больше, но ребята, когда мы ревизию моей презентации делали, сказали, что я оптимист, ставь меньше. Но я бы больше поставил.
    • Поскольку выбор chef или puppet не очевиден и, наверное, не существует какого-то однозначного ответа, на чем выбирать, а нам ни то, ни то не было известно, мы решили ряд самостоятельных не на столько сильно интегрированных в наш основной стек продуктов катить при помощи puppet.
    • Почему Zabbix? Мы пытались все попробовать, что можно катить при помощи рецептов, системы управления конфигурацией, в том числе рецепты Zabbix’а. Это важный момент, потому что я доклады слушал про тесты мониторинга, и совершенно никто не упоминал еще одну определенную проблему, потому что контролировать, отслеживать актуальность, корректность версионность тестов, т.е. обеспечить репозиторий для самих тестов, и управлять ими — это тоже очень важная задача.
      Потому что мало ли кто когда поменял какой тест… Почему у нас была квота 60%, и он должен был орать красным, а мы потом видим, что она 90% и за 2 секунды вылетает в 100%. Т.е. начинается, у него крышу сорвало, он начал писать логи, логи не мог писать, начал в stdout писать о том, что не может писать логи и засрал там все буквально за доли секунды. Но мы узнали о том, что он ломается, когда уже было 90%, а там скорость засера пошла по экспоненте. У нас и был специально выставлен параметр «утилизация дискового пространства на 60%», разбираемся в инцидентах — какого-то черта там 90%. Это важно тоже отслеживать и у меня в смежной дирекции ребята целый процесс у себя определили и задокументировали по разработке тестов мониторинга, их версионированию, контролю за их актуальностью и состоянию. Это тоже, на мой взгляд, очень важный вопрос. И выстраивание конвейера для тестов Zabbix’а в том числе позволяет и этот вопрос тоже решить.
    • .NET. У нас есть .NET приложения, отдельная такая печальная история. Я повелся на Visual Studio Release Management. Говорю: «Ребята, красиво, круто, давайте попробуем», но это, как было сказано в одном из докладов, говно. По факту, мы будем, наверное, на puppet перетаскивать эту историю, потому что это, вообще, не инфраструктура как код, вообще, нет. Т.е. это мышкой ты рисуешь, что и за чем… Не хочу об этом говорить, с этого надо эмигрировать.
    • Мы добились действительно 100% онлайн обновления вебов. Пока что у нас кластер, безусловно, виртуальный, т.е. на одной машине у нас поднятый на apache кластер, соответственно, одну ноду гасим, заливаем новую версию, поднимаем, меняем. Сейчас хотим добавить физически еще дополнительно хосты.
    • Теперь про Oracle. Как я уже сказал, у нас большое количество бизнес-логики реализовано PL/SQL в базе данных. Соответственно, очень важно научиться обновлять без простоев онлайн и Oracle, и базу данных. Какая для этого существует возможность? У Oracle есть для этого инструмент, он называется Edition-Based Redefinition. Что это значит? Код — это пакеты в инстансе базы данных, содержащие PL/SQL код, там скомпилированный. Соответственно, вы берете, льете в новую версию метаданных, обозначаете, перещелкиваете версию, и версию 2 льете в новую версию этих ваших пакетов. После этого, грубо говоря, вашей базе данных даете команду работать с новой версией. Круто, решает именно то, что нам нужно, т.е. отлично решает нашу проблему. Но проблема сохраняется. Почему? Мы это реализовали, а патчи и фиксы мы сейчас катим именно таким образом, но если мы меняем модель данных, если мы меняем структуру таблицы, если мы хоть один ALTER TABLE делаем или мы меняем тип данных на базе, то все это уже не работает, не поддерживается. Это мы не смогли пройти, поэтому версию мы катим все-таки ночью, мы с версией раз в две недели, а патчи какие-то, фиксы быстрые совершенно спокойно катим днем.
    • И команда. Команда — это для меня было самое важное. Во-первых, она полностью перестала сраться. Т.е. команды интегрированы реально друг с другом. Это нам стоило потери нескольких людей. Т.е. люди в какой-то момент времени встали в клинч, не в состоянии друг с другом взаимодействовать, не в состоянии принять ситуацию, что мы больше не враги, что мы друзья. Т.е. просто это противоречит всей их картине мира. В результате этого я пережил тяжелый опыт поглощения недружественного подразделения. Я изначально был из продуктовой дирекции, мы в итоге в продуктовую дирекцию к себе прикладных администраторов
      забрали. Но сейчас у нас действительно, я считаю, что 100% слаженная DevOps команда, разработчики и прикладные админы работают вместе, готовятся все релизы, все рецепты готовятся совместно, обсуждения абсолютно живые, открытые происходят. И еще один аспект в команде для меня ультраважный — я был убежден и очень много сил потратил доказывать, объяснять руководству, что DevOps — это не тот проект, который можно спускать сверху и спрашивать сроки выполнения, это абсурд. Нельзя эту технологию внедрить как обычный проект. Самое важное было — зажечь людей, чтобы люди начали хотеть таким образом жить дальше. Этого мне удалось добиться, и для меня, как для администратора-управленца, это основной аспект гордости в этом проекте. Ребята сами живут этой темой, сами ее двигают, не я прихожу: «Ну, что дальше?», а они приходят: «Короче, мы дальше туда-туда идем, планы у нас следующие». Это, я считаю, очень круто.

    Планы у нас вот такие на ближайшее время, куда мы хотим дальше:



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



    Мы еще в полете. Полет нормальный, это здорово.



    Этот доклад — расшифровка одного из лучших выступлений на конференции по эксплуатации и devops RootConf.

    Кстати, пора рассказывать о том, что мы для вас приготовили в этом году — конференция RootConf 2017 уже через месяц — 5 и 6 июня.

    Дмитрий Столяров, руководитель компании "Флант", постоянного партнёра наших конференций, расскажет об их…

    Опыте работы с Kubernetes в небольших проектах

    Опыт эксплуатации Kubernetes в production есть пока далеко не у всех. Компании «Флант» удалось за последний год внедрить Kubernetes многим клиентам, и именно об этом мы хотим рассказать. Широкий и систематизированный опыт, собранный в этом докладе, должен вызвать интерес у всех: тех, кто только слышал о Docker или начинает его использовать, или выбирает «платформу» (Marathon, Rancher, Kubernetes)… или уже давно что-то использует!

    Мы поделимся своим опытом перехода на Kubernetes и его дальнейшей эксплуатации в проектах среднего размера (до 50 серверов), а именно:

    • Расскажем, что потребуется для перехода на Kubernetes и как к этому подготовиться;
    • Приведем несколько примеров архитектур, ставших уже типовыми для нас;
    • Покажем, как мы обычно выстраиваем CI/CD (с использованием GitLab и dapp) и какие могут быть варианты;
    • Постараемся ответить на вопрос, зачем Kubernetes может быть нужен вашему проекту, систематизировав и разложив по полочкам все (известные нам) плюсы и минусы;
    • И наконец, поделимся сведениями о расположении и размерах подводных камней.


    Вот такие статьи ожидают вас в нашем блоге через полгода :) Ну либо через месяц на конференции RootConf, если вам понравится её программа :)
    Конференции Олега Бунина (Онтико) 682,02
    Конференции Олега Бунина
    Поделиться публикацией
    Комментарии 12
    • +1
      Кто не заберет свои деньги из этого банка? А кто заберет свои деньги из этого банка? Я не знаю, почему есть те, кто не заберет.

      Не очень понял эту мысль. Мне, как клиенту банка, на самом деле все равно где и как банк хранит мои данные. Хранение финансовых данных «не в облаках» никаких гарантий мне не дает.
      Если банк соблюдает все регламенты и стандарты, то пусть хранит данные где хочет.
      • 0
        Согласен. Хотя:
        1. Очень тяжело регламенты соблюсти в облаке;
        2. Законодательно данные должны быть на территории РФ.
        • 0

          Какие данные обязательно должны быть на территории РФ?

          • 0
            Любые.
            Выдержка из ч. 5 ст. 18 ФЗ “О персональных данных”
            «При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети Интернет, оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных в пунктах 2, 3, 4, 8 части 1 статьи 6 настоящего Федерального закона» (ч. 5 ст. 18 ФЗ “О персональных данных”)»


            Там нет уточнения какие именно ПД должны быть. Есть хорошая статья на эту тему.
            Теоретически, можно «поиграться» со словами закона, но это больше добавит проблем, чем преимуществ. К тому же не за горами (просто «вангую») дополнения к закону…
            • 0
              В Вашем комментарии вы не написали изначально, что речь о персональных данных.

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

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

                К сожалению, это только выглядит так просто. На практике при достаточно больших объёмах (а у банков, сотовых операторов именно много данных) очень тяжело всё это работает.
          • 0
            Облако это ведь «просто чужие сервера»?
            Так вот, в банке есть много данных, которые нельзя хранить на чужих серверах.
          • 0
            На самом деле клиентам пофиг. Но в банках параноики работают.
            • 0
              Физикам может и пофиг, многим юрикам — нет.
            • 0
              Заметили такую особенность — Ruby медленно работает на SPARC архитектуре.

              А тогда вопрос возникает: зачем тогда Chef взяли, если нужно было на странные архитектуры заходить? Взяли бы Ansible — ему агент не нужен. С него можно даже (при помощи определённой магии) команды на свитчах выполнять через telnet. Хотя мне Chef нравится написанием рецептов на Ruby, всё же на практике пришлось уйти к анзиблю, чтобы не зависеть от ОС обслуживаемых хостов.
              • 0
                Они начали в 2013. Тогда ansible был еще в альфе.
              • 0
                С какого момента (на каком этапе по мнению автора) у них появился DevOps? Я не совсем уловил этот момент.

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

                Самое читаемое