Когда ломается «облако»: что можно сделать в этой ситуации?



    Совсем недавно из-за проблем с сервисом Amazon S3 случился настоящий «облакалипсис». Сбой в работе стал причиной падения большого количества сайтов и сервисов тех компаний, кто является клиентом Amazon. Проблемы начались вечером 28 февраля, о чем можно было узнать из социальных сетей. Затем стали массово появляться сообщения о неработающих Quora, IFTTT, рассылок Sailthru, Business Insider, Giphy, Medium, Slack, Courser и т.п.

    Сбоили не только сервисы и сайты, многие IoT устройства оказалось невозможно контролировать через интернет (в частности, из-за неработающего IFTTT). Самое интересное то, что до последнего момента статус Amazon S3 показывался, как нормальный. Но многие сотни, а то и тысячи компаний, чьи ресурсы были затронуты проблемой, осознали, что рано или поздно даже очень надежное «облако» может рухнуть, накрыв всех своими обломками. Можно ли что-то сделать в такой ситуации?

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

    Способы, позволяющие избежать проблем со своими серверами в том случае, если облако, в котором они работают, падает, сильно отличаются от методов, используемых дата-центрами для повышения аптайма и «стрессоустойчивости» (например, дублирование различных систем). Для защиты своих сервисов и удаленных данных можно использовать копии, размещенные на виртуальных машинах в дата-центрах из различных регионов, а также использовать базу данных, которая охватывает несколько ЦОД.

    Этот способ можно использовать и в рамках работы с одним провайдером, но более надежно использовать и услуги других облачных компаний, включая Microsoft Azure или Google Cloud Platform в дополнение к тому же AWS. Понятно, что это дороже, но здесь, как и в обычном случае, стоит подумать над тем, стоит ли овчинка выделки. Если да, например, сервис или сайт должен работать постоянно, то можно предпринять такие методы предосторожности. «Мультоблачная» архитектура, вот как это можно назвать.

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

    После падения Amazon S3 те клиенты AWS, кто работал с Cloudflare, почти не испытывали проблем.



    Напомним, что все начиналось с S3 в 2006 году. Первый публичный сервис, который Amazon запустил — именно облачное файловое хранилище. Виртуалки (EC2) появились заметно позже.

    Вот еще один скриншот клиента Амазона — Российской ИТ компании. У них не работало 45 сервисов:



    Данные можно хранить в грузовиках (тоже от Amazon), но и это не всегда является выходом

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

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

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

    Еще один тренд, связанный с предыдущими — это появление все большего числа инструментов контейнерной оркестровки, вроде Docker, Kubernetes, и DC/OS от Mesosphere. Их тоже стоит опробовать в работе, с ними принцип мультиоблачной инфраструктуры организовать гораздо проще, чем в обычном случае.

    Человеческий фактор


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



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

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

    King Servers 77,55
    Хостинг-провайдер «King Servers»
    Поделиться публикацией
    Комментарии 127
      0
      Кто-нибудь уже шутил на тему:
      sudo rm -rf /
      Ой, кажется мы не тестовую ферму форматнули…
        0

        Обычно в продакшен пускается только CI + chef/puppet/ansible..

          +2
          Позволяющие форматнуть не один, а сразу все сервера!
        –6
        Облачные сервисы умрут также быстро как появились, когда в массы придёт понимание рисков.
          +5
          ПК никогда не станет персональным…
          Кому нужно больше 640К памяти?
          Никто не будет пользоваться Bitcoin, скоро он вымрет
          Да кому нужны эти смартфоны?
          JavaScript не пригоден для серьезных приложений…
          И т.д. и т.п.
            +3
            когда в массы придёт понимание рисков

            Значит никогда.
              +1

              Как будто свое железо не несет никаких рисков.


              Большая компания еще может содержать штат админов и свой небольшой дата-центр, а маленький стартап не может так разбрасываться деньгами (и временем). Облако в таком случае намного надёжнее: что делать, если упали свои сервера, а админ в самолете или в бане парится? А в компаниях типа AWS тонна админов дежурит круглые сутки.

              0
              Можно подумать, держать железо у себя и админить его самому — это менее рискованно. Вряд ли вы сможете себе позволить настолько же надёжное железо и настолько же квалифицированных админов за сопоставимые деньги.
                +2

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

                  0

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


                  Единственный приемлемый выход, это держать резерв в "преднатяге": 70% AWS, 30% кто-нибудь другой (хорошо если клиентов можно легко отделить друг от друга). Технических сложностей здесь будет много, но в целом они решаемые, даже если вы завязны на S3.

                +3
                Понятно, что это дороже, но здесь, как и в обычном случае, стоит подумать над тем, стоит ли овчинка выделки. Если да, например, сервис или сайт должен работать постоянно, то можно предпринять такие методы предосторожности. «Мультоблачная» архитектура, вот как это можно назвать.

                И под каждого облачного провайдера городить свои обвязки над их API? Не проще ли взять решения от VMWare или, даже, Microsoft, разместить на своих или арендованных серверах в разных датацентрах и получить своё облако?

                  0
                  так конечно проще, но вдруг так уж случится, что весь azure разом упадет? тут ведь вопрос в надежности
                    0

                    Я про Hyper-V

                      0
                      Скорее лучше тогда OpenStack. Большая часть проектов OpenStack совместима по API с AWS, и можно сделать гибридное облако, часть инстансов деплоя паппетами/ансиблами в private cloud, а часть в AWS.

                      VmWare и Hyper-V это устаревшее, прошлая парадигма — Enterprise Virtualization. В Девопс не вписывается.
                    0

                    У этого решения свои минусы:


                    • деньги (свое железо нельзя быстро масштабировать);
                    • сложность поддержки и масштабирования (которая ложится на ваши плечи, а там геморроя прилично);
                    • надежность (пока вы научитесь делать такой же uptime, как у amazon, ваш downtime будет больше, чем у профессиональных облаков);
                    • облако нужно будет настраивать самому с нуля (Amazon и прочие берут деньги не только за ресурсы, но и за сервис, который они выстраивали не один год).

                    На своем железе проще вообще не делать облако.

                      0

                      Как вариант масштабирования: приобретать у облачных провайдеров исключительно полноценные "голые" виртуальные машины, перекладывая на их плечи масштабирование железа, но оставляя за собой полный контроль за средой исполнения программ. А то почитаешь про облака, воодушевишься, начнешь разбираться и выясняется: вот вам виртуальная машина, но она стейтлесс, файлы храните вот в этом хранилище, причем работайте с ним по вот этому протоколу, а не просто примонтируйте к машине, и вообще нужную вам программу на этой машине вы собрать не можете, и СУБД только нашу нужно использовать, потому что наше хранилище не обеспечит нормальную скорость для вашей базы, даже если вы как-то установите свою СУБД и как-то примонтируете хранилище. И это полбеды, основная в том, что у каждого провайдера свои хранилища, свои СУБД и т. п., со своими API,

                        0
                        деньги (свое железо нельзя быстро масштабировать);


                        Hybrid cloud?

                        сложность поддержки и масштабирования (которая ложится на ваши плечи, а там геморроя прилично);
                        надежность (пока вы научитесь делать такой же uptime, как у amazon, ваш downtime будет больше, чем у профессиональных облаков);


                        OpenStack? Там хватает своих глюков, но всё же

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


                        Не Vanilla openstack, а какой-то дистрибутив OpenStack? Fuel там или RDO?
                          0
                          Hybrid cloud?

                          Вот тут поподробнее пожалуйста, что вы имеете в виду.


                          OpenStack? Там хватает своих глюков, но всё же

                          Да, на сервера можно установить его (тут и выбор небольшой в общем-то).
                          А в головы админов нужно установить знания и опыт для работы с ними в абстрактном мире.
                          А потом установить знания и опыт приспособления этого продукта под конкретный продакшен.
                          Вот в матрице хорошо, кнопку нажал, "i know kung fu" и понеслась.
                          А в реале это курсы или самоучество, а потом долгий путь "грабли -> опыт, грабли -> опыт".


                          Не Vanilla openstack, а какой-то дистрибутив?

                          А этот дистрибутив настроит sysctl под конкретный прод?
                          Или укажет правильные параметры chunk size при создении рейда и выравнивание при создании ФС?
                          Добавит openstack в текущую систему мониторинга (уже развернутую)?
                          Напишет документацию про себя в местной wiki?
                          Прикрутит имеющуюся систему авторизации?
                          Загрузит образы?
                          Раздаст права?
                          Настроит бекапы?


                          А так да, можно выбрать правильный дистрибутив и развернуть там openstack за пол часа.
                          Просто это 1% от всей работы.

                            0
                            А этот дистрибутив настроит sysctl под конкретный прод?


                            Эм, это всё в инстансах настраивается

                            Добавит openstack в текущую систему мониторинга (уже развернутую)?


                            А в головы админов нужно установить знания и опыт для работы с ними в абстрактном мире.
                            Добавит openstack в текущую систему мониторинга (уже развернутую)?
                            Прикрутит имеющуюся систему авторизации?


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

                            Вот тут поподробнее пожалуйста, что вы имеете в виду.


                            Можно иметь и OpenStack и AWS. Благо API почти те же самые, можно юзать один код для деплоя в своё облако и в публичное.
                              0
                              А чем разработчик со скиллами админа, решающий админские задачи, отличается от просто админа, кроме того, что он перешёл в админство из разработки?
                                0
                                А чем разработчик со скиллами админа, решающий админские задачи, отличается от просто админа, кроме того, что он перешёл в админство из разработки?


                                Тем, что вписывается в команду Dev(в отличие от админов, которые для команды разработчиков всегда как инопланетяне), работает в рамках AGILE(Sprint, etc), и по-большей части пишет код(ансибл, паппет, etc), а не правит что-то руками в проде, а так же не боится слов «юнит тестирование», continius integration/delivery?
                                  0
                                  в отличие от админов, которые для команды разработчиков всегда как инопланетяне

                                  А вот это, на мой взгляд, в современном мире как раз исправляется.
                                  У админов появляются спринты и скрамы (свои), puppet/salt/ лежит в git с разными ветками и ci сервисом, и т.д.
                                  Вот тут прогресс есть.
                                  Но увольнять админов пока рано.

                                    0
                                    У админов появляются спринты и скрамы (свои), puppet/salt/ лежит в git с разными ветками и ci сервисом, и т.д.


                                    … И они перестают быть админами, кстати часто попутно начиная вместе с dev править код приложения, изучая на хорошем уровне несколько языков, вроде Python, ruby, etc.

                                    т.е. ровно то, о чём я говорила — или переучиваются в другую профессию, или оказываются уволенными.
                                      0
                                      … И они перестают быть админами

                                      Почему? Они же продолжают выполнять админские задачи. От того, что конфиги лежат в puppet и генерируются из шаблонов, они не перестают быть конфигами.
                                      Вы скорее говорите про переход из изолированного админа в DevOps админа.
                                      С этим согласен.
                                      Но административные обязанности от этого он выполнять не перестанет, просто будет выполнять их с другими инструментами.
                                      Сами обязанности никуда не денутся.
                                      Соответственно и увольнять админов просто от перехода в DevOps никто не будет.


                                      изучая на хорошем уровне несколько языков, вроде Python, ruby, etc

                                      В качестве оффтопа, давайте разовьем вашу мысль.
                                      Что значит "на хорошем уровне"? Мидл, сеньор?
                                      Наверное, не лучше, чем синьор программисты в той же компании.
                                      Программисты-то тратят на написание кода и совершенствование все рабочее время, а админы — некоторую часть (не самую большую).
                                      И даже если админ хорошо наловчится с тем языком, который используется в компании, что потом?
                                      Руководство начнет накидывать ему программисткие задачи?
                                      В роль программиста он войдет в роли начинающего, потому что ему нужно будет прочитать вики и доки, принятые в этой компании — соглашения об именах, текущий workflow и т.д.
                                      И начать с простых задач. А админские задачи кто будет делать в это время?
                                      Компания просто поменяет мидл/сеньор админа на джуна программиста.
                                      А если совмещать, получится админ на пол ставки и джун на пол ставки.
                                      А зп админ вряд ли захочет поменять на более низкую.

                                        0
                                        Sysadmins are far from being dead or replaced by “Devops” folks. Pointing and clicking a few times to instantly spin up a new server or database for the Devops guys might be a quick way to get a server online for them to push code. Building and deploying servers are the least taxing task a sysadmin has to deal with. Patch management, security scanning and risk mitigation, disaster recovery plans and testing them. Proper documentation. Firmware updates, hardware failures, network devices. A sysadmin does many things, many behind the scenes to keep things working. Someone’s gotta run all those blade chassis, SAN array’s, networking firewalls, routers, load balancers ect….you think a guy who writes apps all day has the time or will to attend to the mundane care and feeding of a large I.T. system? You think they’ll know what to do when part of that converged cloud platform has a hardware failure and alarms are going off all over the place? I don’t think so. Sysadmins will always exist. We just may all end up in large datacenters supporting clouds.
                                        http://www.juliandunn.net/2012/01/13/chef-devops-and-the-death-of-system-administration/#comment-9061
                                          0
                                          Patch management


                                          И что? Тот же патч менеджмент у всех членов команды. Выходит zero дей на какой-то питоновский pip-модуль, и у всех болит голова, как заапдейтить джангу так, что бы не сломалась.
                                          Тоже самое и с каким-нибудь банальным nginx, он никак не отличается от этого питоновского модуля. Всё равно обновлён прод будет через накатывание новой версии конфигурации. Никакой разницы

                                          Proper documentation.


                                          Вообще-то её ведут технические писатели. Ну или вообще все — в том числе все-все кодеры.

                                          disaster recovery plans and testing them


                                          Так это тоже всё в рамках кодинга. Пишите плейбук для дизастер рекавери, и тестируете его, как ещё?

                                          . Firmware updates


                                          Ээээ, как бы в больших конторах уже лет 10 как служба дата-центра это отдельный департамент от админов, разработчиков и пр. Они занимаются железяками, а даже одмин до девопса просто просил IP KVM.
                                          Ну и в большинстве контор со своим железом оно тупо арендованное.

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

                                          etworking firewalls, routers, load balancers ect


                                          И что? Как это отменяет то, что для девопса каждая эта штука это просто… класс (в программерском смысле)?
                                            0
                                            И что? Как это отменяет то, что для девопса каждая эта штука это просто… класс (в программерском смысле)?

                                            Кажется, я понял, в чем дело. Вы путаете тех, кто настраивает с теми, кто пользуется уже настроенным.
                                            Для админа load balancer — это не только класс. Да, удобно иметь модуль для настройки балансировщика в puppet. Но админ должен ещё и понимать нюансы работы этого балансировщика, что там происходит под капотом, на нижнем уровне.
                                            Если я вас правильно понял, DevOps это знать не обязательно.
                                            Вот такая разница вырисовывается.

                                              0
                                              Если я вас правильно понял, DevOps это знать не обязательно.


                                              Обязательно, или no hire. Так же обязательно нужно быть — если ты миддл девопс — как минимум джуниор кодером в том, куда нанимаешься девопсом (Java/Spring, Python/Django, Ruby/Rails или что-то ещё тут не важно).
                                              А если сеньёр девопс, то миддл разработчиком на этой платформе.

                                              Т.е. прям тем, который уверенно прошёл бы интервью, не сообщая об админском бэкграунде.

                                              что там происходит под капотом, на нижнем уровне.


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

                                              Но часто можно и не разбираться, а просто взять хорошую библиотеку. Вообще на рынке не интересен никому «настройщик балансеров» (ну разве что Facebook какой такого SRE бы нанял), всем интересны люди с админскими и кодерскими скиллами, способными разобраться в чём угодно.
                                              В том числе, способные написать класс для паппета для любой, самой неведомой фигни, прочитав по ней документацию, бестпрактисы, погоняв её на стендах, или исходя из своего опыта с ней.
                                                0
                                                Обязательно, или no hire
                                                Но часто можно и не разбираться, а просто взять хорошую библиотеку.

                                                Опять противоречие :) Но ваше видение я понял.

                                          0
                                          Но административные обязанности от этого он выполнять не перестанет, просто будет выполнять их с другими инструментами.


                                          У DevOps, бывает, и доступа к prod нет(может быть, например, у тимлида — пишите хороший код, который будет работать нормально не только на лабе!). Или есть доступ у всей команды, просто у девопс специализация немножко больше на деплое (но он так же как и другая команда может фиксить баги в джанго-приложении, которое пишет команда, его бы не наняли, если бы он, будучи сеньёр девопсом, не знал Python/Django на уровне хорошего Миддл девелопера), у другого разработчика в Angular, итд, но все почти «фуллстеки»
                                            0

                                            Тогда у вас несостыковка в рассуждениях.
                                            Я говорил про продакшен админов. Вы сказали, что теперь они называются DevOps. Теперь вы говорите, что у DevOps доступа к проду может и нет. А как тогда называются люди, у которых есть доступ к проду? Кто-то же этот самый прод и должен настраивать :)


                                            Мне кажется, вы забываете о тех, кто админит ту инфраструктуру, в которой так удобно DevOps'ить парой команд.

                                              0
                                              как тогда называются люди, у которых есть доступ к проду?


                                              Если стартап, то это может быть тимлид, может быть девопс, а может быть вся команда

                                              Кто-то же этот самый прод и должен настраивать :)


                                              Зачем вообще его настраивать? Есть лаба, ей заведует SRE/Devops, есть паппет и ансибл, они настраивают лабу, а потом тоже самое выкатываешь в прод. Т.е. ответ на ваш вопрос — это вообще не люди, а configuration management tools :)
                                                +2
                                                Зачем вообще его настраивать?

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

                                                  0
                                                  Давайте назовем это «запускать,


                                                  Что?

                                                  поддерживать


                                                  Вся команда поддерживает же

                                                  реагировать на инциденты


                                                  Тоже вся команда. Сломался у Вас дико сложный SQL запрос, который Вы не писали, и что? Как „одмин“ со „слабыми программерскими скиллами“ разберётся?

                                                  Если ситуация простая, то её решит тот, кто первый увидит СМС-ку или автоматический звонок мониторинга, например, откатив назад конфигурацию на проде на прошлый релиз.

                                                  А в больших компаниях есть люди — operations. У них нет глубоких скиллов в том, что бы что-то „настраивать“, как Вы пишите выше. Они сидят, смотрят в мониторинг, и если что-то упало, чинят по инструкциям, или звонят тому разработчику, с которым эта проблема ralated (вовсе не обязательно с девопсом!)

                                                  искать причины ошибок,


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

                                                  решать проблемы, в том числе быстродействия


                                                  Да, проблемы быстродействия это то, что роднит системных программистов и devops. Но это не делает их админами :) Разве что чуть-чуть.
                                                    0
                                                    Мне кажется что описанное вами больше похоже на NoOps. Вся команда делает это. А команда ведь у вас именно из программистов состоит, верно?
                                                      0
                                                      А команда ведь у вас именно из программистов состоит, верно?


                                                      Да

                                                      Мне кажется что описанное вами больше похоже на NoOps.


                                                      не важно как это называется. Noops, devops. SRE… Главное, что никто не боится кодить, и вообще любит это делать. То, что DevOps имеет админские скиллы не особенно важно — их и системные разработчики всегда имеют (но правда без опыта и рефлексов, касающихся поиска проблем на нагруженных и плохо работающих системах).
                                      0
                                      Ну и что? Это то же самое админство, просто можно админить офисы, а можно админить процесс разработки.
                                        0
                                        Конечно, и водитель тот же кучер. Можно ухаживать за лошадью, кормить её сеном, подковывать, а можно заливать в бак машины бензин, менять пробитые колёса и перебирать мотор о_О
                                          0
                                          При появлении автомобилей лошади стали почти не нужны. Про исчезновение офисов говорить пока рано.
                                            0
                                            Про исчезновение офисов говорить пока рано.


                                            Мы говорим об исчезновении админов :) Если человек большую часть дня пишет код, пусть и на том же Puppet, он уже не админ. По тому, что он пишет код.
                                              +1

                                              Большую часть дня пишет код для puppet. А меньшую часть дня смотрит, почему что-то упало на проде, выводит из боя, курит логи, tcpdump, strace, не говоря уже о ps/top/htop/…
                                              А так же получает новое железо, ставит в ДЦ, накатывает ОС, заводит в разные системы, тюнит, следит за графиками и т.д.
                                              Работу продакшен админов хорошо характеризует название "Служба эксплуатации".
                                              Они отвечают за то, чтобы все, что написалось в дев среде (включая DevOps) так же хорошо работало на проде.

                                                0
                                                Они отвечают за то, чтобы все, что написалось в дев среде (включая DevOps) так же хорошо работало на проде.


                                                Нет. Если что-то плохо работает в проде, то девопс виноват, что сделал плохую лабу.

                                                Эксплуатация же не должна быть особенно скиллистой. Их дело чуть что не по инструкции, и мониторинг горит, звонить разработчикам, и tcpdump им нужен только в тех объёмах, что бы составить багрепорт.
                                                  0

                                                  Да, звонила мне такая эксплуатация: "система не работает ни у кого", пытаюсь зайти как обычный юзер, как суперюзер — реально не работает, 500 отдаёт, пробегаюсь по серверам и вижу, что место на диске продакшен базы кончилось, причём алерт от мониторинга в базе лежит. Говорю: "расширяйте или чистите диск". Вот нужно для этого разработчика будить? Или когда апп-сервер не видит БД-сервер из-за каких-то проблем с сетью у хостера? Эксплуатация должна дергать разработчиков, когда локализовала источник проблемы и им оказывается разработанный ими код или его прямые зависимости. В случае с местом на дисках — если только система начала потреблять больше пространства чем заявлено, типа заявлено 10 кбайт на одну транзакцию, а тратится 100.

                                                    0
                                                    Вот нужно для этого разработчика будить?


                                                    Да, если разработчики отвечают ещё и за инфраструктуру, а отдельный Ops отсутствует, как это бывает в компаниях с DevOps / NoOps.
                                                    Эффективность такой организации лично у меня вызывает сомнения, но такие компании и подходы существуют.

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

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


                                                      Всё отлично :) Я думаю, что рано или поздно все так будут работать
                                                        0

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

                                                          0
                                                          Если выделенная эксплуатация есть, то я не совсем понял в чём бизнес идея. Перевесить побольше обязанностей эксплуатации на разработчиков? А смысл?
                                                            0

                                                            Улучшить время реакции на проблемы.

                                                              0
                                                              Но ведь проблемы с сетью, с переполненным диском, с несработавшим фейловером, с перегрузкой сервера БД, и прочие проблемы инфраструктуры разработчик не решит быстрее чем эта самая эксплуатация. Как это улучшит время реакции?
                                                                0
                                                                разработчик не решит быстрее чем эта самая эксплуатация


                                                                Решит, он напишет инструкцию на:

                                                                Но ведь проблемы с сетью, с переполненным диском, с несработавшим фейловером, с перегрузкой сервера БД


                                                                  0

                                                                  По инструкции будет медленнее в среднем.

                                                                    +1
                                                                    Программисты пишут инструкции как решать проблемы с сетью? Ужас какой.
                                                          0
                                                          Вот нужно для этого разработчика будить?


                                                          Вы не поняли. Достаточно эксплуатации и разработчиков(включая девопса).

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


                                                          У эксплуатации должен быть рут и инструкции как действовать в такой ситуации. Это не суперсложный челлендж, с которой справится любой человек (при наличии инструкции), который по пользовался bash'ем полгода.
                                                            0

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


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

                                                      0
                                                      Если человек большую часть дня пишет код, то это программист. В данном случае программист на Puppet DSL.
                                                      Но я себе DevOps как то более разнообразно представлял чем 5-7 часов в день писать код на одном и том же языке.
                                                        0
                                                        Если человек большую часть дня пишет код, то это программист. В данном случае программист на Puppet DSL.


                                                        DevOps же :) А так, идеальный DevOps да, это такой программист, ИМХО. Разновидность, вроде системного или любого другого.

                                                        чем 5-7 часов в день писать код на одном и том же языке.


                                                        Разумеется, ещё всегда на bash, и почти каждый день на python/php/ruby/perl/etc
                                                          0
                                                          Ну и, наконец, мы тут все должны понимать, что обсуждаем внутреннюю кухню компаний, производящих софт. При этом большинство компаний на планете софт не производит, а их ИТ инфраструктура служит для обслуживания бизнеса.

                                                          Хороший пример банки — там может не быть Dev отдела вообще (разработка, как непрофильная деятельность, отдана подрядчикам), но при этом тысячи рабочих станций, сотни отделений по всей стране, и огромные БД, от работы которых зависит бизнес.
                                                          Всё это к тому же построено на принципах 10-тилетней давности, а в облако вынести почти ничего нельзя из соображений безопасности.

                                                          Никакой DevOps к ним не применим по причине отсутствия какого бы то ни было Dev.
                                                            0

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


                                                            В ИТ-зависимых не ИТ-бизнесах со заказными разработками самая плохое, что может быть — связь разработчиков с эксплуатацией через бизнес. Ну, вернее, самое плохое — отсутствие связи, но это на практике не встречал.

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


                                                              Ну так всё уходит в облака. Не IT-компании покупают SaaS приложения, и нанимают из айти специалистов только эникейщиков.
                                                              IT-же не-технологические компании постепенно погибают в неравной борьбе с компаниями технологическими, которые всё больше и больше пускают под нож вакансии классических админов (которым уже был нанесён фатальный ущерб, когда началось победное шествие SaaS'ов по не-ИТ компаниям, и которые стали массово сокращать настройщиков эксченджей и прочих майкрософт дайнамикс — классических одминов)
                                                              Уже, кстати, есть SaaS для замены AD. Догадываетесь что ждёт виндовых не-девопсов? (такие тоже есть, пишут автоматизацию для Azure на powershell и, наверное, код C# — я честно говоря не знаю в подробностях как они работают)

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


                                                              Ой, о чём Вы говорите? Нужно от одного до десятка эникейщиков (в зависимости от размера компании), которые будут рассказывать юзерам, куда ткнуть в SaaS приложении.

                                                              Зачем я учавствую в этом споре? А я помочь хочу. Учите кодинг, всерьёз, алгоритмы, популярные фреймворки, итд — тогда у Вас всегда будет работа с админскими задачами :) А в другой ситуации нет. На западном рынке эти тенденции видны уже невооружённым глазом, но и в остальной мир это через год-другой-третий придёт.
                                                              Потерять работу, особенно в IT, с её уровнем зарплат, может быть очень обидно.
                                                              Нужно преодолеть инстинктивный страх перед написанием приложений, который есть у многих одминов.
                                                              Уверяю Всех, что нет никакой магии в том, что бы, скажем, нарисовать демон на питоне. Это требует всего-навсего больше времени, чем красивый однострочник на баше.
                                                                0
                                                                Ой, о чём Вы говорите? Нужно от одного до десятка эникейщиков (в зависимости от размера компании), которые будут рассказывать юзерам, куда ткнуть в SaaS приложении.

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

                                                                  0
                                                                  от рабочих мест пользователей


                                                                  Эникейщик?

                                                                  Как минимум должен быть кто-то, кто будет поддерживать сетевую инфраструктуру


                                                                  SDN ;)? Ладно, шучу. Интернет-провайдер?

                                                                  P.S. ноков, кстати, тоже ждут увольнения — SDN рано или поздно допилят.
                                                                    0

                                                                    Эникейщик поднимет локальную сеть предприятия (пускай и виртуальную) с единой аутентификацией и авторизацией, с впн-доступами, с резервными каналами для пользователей от пары десятков разных провайдеров по стране?


                                                                    Как насчёт интеграции сервисов между собой? Бэкапов данных из сервисов? Их отказов?

                                                                      0
                                                                      Нет, в концепции DevOps этим будет заниматься программист.
                                                                        0
                                                                        Эникейщик поднимет локальную сеть предприятия (пускай и виртуальную) с единой аутентификацией и авторизацией, с впн-доступами, с резервными каналами для пользователей от пары десятков разных провайдеров по стране?


                                                                        Это сделает IT-компания интегратор
                                                                          +1

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

                                                                            0
                                                                            и нужны люди, которые это будут… и поддерживать.


                                                                            Эникейщик же. Он останется в штате. Но эникейщик не админ, и речи о том, что бы уволить эникейщиков не идёт.
                                                                              +1
                                                                              А эникейщик это какая-то отдельная профессия? Это разве не младший админ?
                                                                                0

                                                                                Где у вас грань между эникейщиками и админами?

                                                                                  0
                                                                                  Админ обычно асоциальный чувак с бородой и пивом как бы эникей это же хэлпдеск, клиентская служба. Полу-технарь, полу-гуманитарий (специалист по общению с юзверями)…
                                                                                  Старший эникей это старший хэлпдеск инженер, а дальше можно развиваться куда-то в направлении консалтинга в ИТ компаниях.
                                                                                  Задач по тому, что бы стать продвинутым настройщиком SaaS'ов же просто нет на рынке. Если нужно что-то сложное, пишешь в саппорт SaaS'а, если они посылают лесом, покупаешь другой SaaS, который может твою задачу
                                                                                    0

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


                                                                                    Они обеспечивают, как минимум, работу сети предприятия (не суть один это офис с локалкой и двумя каналами от разных провайдеров или несколько виртуальных частных сеть на несколько государств со шлюзами между ними и с несколькими десятками провайдеров на последней мили, как у нас), конфигурируют роутеры, делают бэкапы и восстанавливают данные, в случае если своего софта нет, только SaaS, то обеспечивают интеграцию разных сервисов, выдают хэпдеску данные для конфигурирования конечных пользовательских устройств или обеспечивают их автоматическое конфигурирование инструментами типа DHCP, управляют доступами на уровне сетевых протоколов, организуют мониторинг доступности и функциональности сервисов (опять же не важно, SaaS или классических), и прочая, и прочая, и прочая. Даже при полном переходе операционного, учетного и аналитического софта на SaaS от этих задач никуда не деться. Да, их можно отдать на подряд, но это лишь административно-правовое разделение, технически должны быть люди, знающие инфраструктуру предприятия как свои пять пальцев, а не начинающие реакцию на инцидент от хелпдеска с вопроса ему "а у вас чисто локалка? IP и шлюзы ручками прописываете или по DHCP"

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

                                                                                      Да и там можно без них обойтись — на аутсорс тот же отдать, или завести dev отдел
                                                                                        0

                                                                                        Ну вот нам нужны, компания не крупная — и 1000 человек нет. Дев-отдел завели — мы разрабатываем. Админы — есть, они обслуживают сетевую инфраструктуру и сервера для нашего и коробочного софта типа 1С. Хелпдеск — есть, они работают с юзерами и при необходимости ридерктят на нас или админов. Допустим, наш отдел разгонят в пользу SaaS решений, и даже 1С будет как SaaS, но админов-то разогнать нельзя, просто не будет работать инфраструктура, хелпдеск при отказе, например, магистрального роутера поменять его не сможет, или новую впн-сеть создать. Допустим завести девопсов и разогнать админов — надо три девопса. Допустим завести девопса и не разгонять админов — почти идеально с точки зрения функциональности, но дорого.

                                                                                          0
                                                                                          хелпдеск при отказе, например, магистрального роутера поменять его не сможет, или новую впн-сеть создать.


                                                                                          Это по-идее скоро будет автоматизировано, когда, наконец, SDN допилят

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

                                                                                          А выдача VPN и сейчас не требует высокой квалификации (у нас, например, он выдается Ansible, т.е. нужно просто прописать новый элемент в dict, закоммить в гит, и всё. И прикрутить к нему вебморду на PHP/Django — дело нескольких часов)

                                                                                          Допустим завести девопсов и разогнать админов — надо три девопса.


                                                                                          Почему Вы так думаете? Вы уже не в первый раз высказываете эту идею. DevOps же автоматизирует рутину, или он не девопс… Если её нельзя автоматизировать, то выкинет софт/утилиты, которые нельзя автоматизировать, и заведёт другие.
                                                                                            0

                                                                                            Не выдача VPN-доступов юзерам, а создание новой сети и связи её с существующими.


                                                                                            Кто-то должен ручками админить то, что не автоматизируется и(или) рутиной не является.


                                                                                            Чтобы обеспечить поддержку бизнеса 24/7 во всех ситуациях, а не только автоматизируемых и рутинных.

                                                                                              0
                                                                                              Не выдача VPN-доступов юзерам, а создание новой сети и связи её с существующими


                                                                                              Это тоже уже нормально автоматизируется :)

                                                                                              Тут всё может быть куда проще, т.к. не циски, которые не понятно как работают со своими проприетарными протоколами, а простые и понятные OpenVPN, openvswitch, neutron(в опенстеке), AWS VPC итд. Всё документировано, открыто, и иногда можно и исходники глянуть

                                                                                              Чтобы обеспечить поддержку бизнеса 24/7 во всех ситуациях,


                                                                                              Для большинства бизнесов не нужна поддержка IT инфраструктуры 24/7. Для тех, для кого нужна, эта задача бизнес-критикал, и её стоит автоматизировать.
                                                                                              Причём даже для них не нужна поддержка 24/7 абсолютно всех сервисов.
                                                                                                0

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


                                                                                                Поддержку 24/7 невозможно автоматизировать, имхо, даже для части критичных серверов. Слишком много неопределенности. Ну, например, недоступно облако из офиса (своих серверов же нет) ни по одному из каналов. Может кабеля перерубили, может точка обмена доступом легла, а может облако лежит, как давеча Амазон лежал несколько часов. Это то, что мне в голову пришло. А вариантов может быть куда больше.

                                                                                                  0
                                                                                                  Ну, например, недоступно облако из офиса (своих серверов же нет) ни по одному из каналов.


                                                                                                  Значит, это приемлимо.

                                                                                                  а может облако лежит


                                                                                                  И это тоже.

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

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

                                                                                                      0
                                                                                                      По вашим словам у меня получается картинка, что интегратор — это просто админы (ну или ИТ-отдел в целом) на аутсорсе,


                                                                                                      разработчики. Разрабатывают и поставляют заказчику систему. Почему админы?
                                                                                                        0

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

                                                                                                          0
                                                                                                          Ну, в нашем примере с облаком, скорее всего интегратор установит некое сетевое оборудование, чаще всего Cisco или Juniper. Разве эти железки у интеграторов разработчики настраивают?
                                                                                                            0
                                                                                                            SDN же
                                                                                                              0
                                                                                                              Но для SDN сейчас тоже используется оборудование Cisco, Juniper и HPE в основном. Разве его установка не требуют участия сетевых инженеров и выполняется разработчиками?
                                                                                                                0
                                                                                                                . Разве его установка не требуют участия сетевых инженеров и выполняется разработчиками?


                                                                                                                Это будут сетевые DevOps — которые могут в циски и в кодинг
                                                    0
                                                    Эм, это всё в инстансах настраивается

                                                    На хост машине тоже есть sysctl. Хотя согласен, его там мало для чего нужно менять. Это больше для LXC актуально.


                                                    Ну вроде предполагается, что в современном мире админы уже не нужны

                                                    Я даже не знаю, кем такое предполагается и где этот современный мир :)
                                                    Вот у вас много знакомых мидл/сеньор разработчиков и по соместительству мидл/сеньор админов?
                                                    Так, чтобы и на работе и код писали и всякие системы разворачивали и поддерживали.
                                                    У меня таких знакомых, может быть, 1-2.
                                                    Ну и такие люди вполне заслуженно могут требовать высокие зарплаты.
                                                    Поэтому для того же работодателя удобнее, проще и выгоднее разделять эти должности на разных людей.
                                                    Один разработчик и один админ будут дешевле, чем два человека-оркестра.

                                                      0
                                                      Это больше для LXC актуально.


                                                      Да, кстати, нафига он нужен, если есть Docker? ну если очень хочется контейнеры как виртуалки, есть же нормальная штука — OpenVZ

                                                      Вот у вас много знакомых мидл/сеньор разработчиков и по соместительству мидл/сеньор админов?


                                                      Да

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


                                                      Нет. Посмотрите количество вакансии «DevOps» на Индиде и Линкедине
                                                        0
                                                        Посмотрите количество вакансии «DevOps» на Индиде и Линкедине

                                                        Посмотрел на Индиде, забил DevOps и тупо открыл первые 10.



                                                        Везде указываются, что нужны хорошие навыки по администрированию (Experience in administration) и знание админских скриптовых языков (bash, иногда ещё python).
                                                        Иногда в желательных навыках пишут опыт разработки на каком-то языке.


                                                        То есть, что мы имеем. На должность DevOps нужен хороший админ, который знаком с разработкой. Но не хороший разработчик, который знаком с админством. Поэтому в современном мире админы нужны. Просто кто-то может считать, что это не админы, а DevOps/engineer/..., но это уже спор об именовании, а не о функции.


                                                        Да, кстати, нафига он нужен, если есть Docker? ну если очень хочется контейнеры как виртуалки, есть же нормальная штука — OpenVZ

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

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


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


                                                            Это одно и то же. Коммутативность же. Хороший DevOps это хороший разработчик и админ. Такие дела.
                                                              0
                                                              И часто такое встречается, чтоб человек был хорош и в том и в другом?
                                                              Потому что это всё равно что быть сразу хорошим хирургом и хорошим психиатром.
                                                                0
                                                                И часто такое встречается, чтоб человек был хорош и в том и в другом?


                                                                Так рынок сейчас опять платит за универсальность в этом вопросе :)
                                                                  0
                                                                  Работодателям совершенно естественно хотеть кого-то, кто может выполнять работу сразу нескольких специалистов.
                                                                  Но это не значит что такие универсалы есть и хороши во всём.
                                                                  Разделение на программистов и системных инженеров было ещё во времена ENIAC. Это всё таки разные специальности.
                                                                    0
                                                                    Разделение на программистов и системных инженеров было ещё во времена ENIAC. Это всё таки разные специальности.


                                                                    Разделение на кучеров и пассажиров возникло ещё до времён рессорных карет — пожалуй, оно возникло с момента появления колеса. И что? Это разве помешало профессии кучера исчезнуть? А после неё, например, исчезла профессия наборщиц перфокарт, тоже ИТ профессия кстати :)
                                                                      0
                                                                      Профессия кучера сейчас называется «водитель», и суть её не изменилась (управление и уход за транспортным средством), изменилось лишь транспортное средство.
                                                                      Но вымереть она в ближайшие лет 30 и вправду может — с появлением беспилотных авто.

                                                                      Вымрут ли системные инженеры? Не знаю, но судя по вашим комментариям, в вашей организации их нет — только программисты. Но в других организация вакансии пока есть, да и от C++ программиста пока не очень часто требуется умение настроить Nginx и Zabbix.
                                                                        0

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

                                                                          0
                                                                          Профессия кучера сейчас называется «водитель», и суть её не изменилась (управление и уход за транспортным средством), изменилось лишь транспортное средство.


                                                                          Лол, ну если Вы считаете, что водитель и кучер это одна профессия, то, с таким сомнительным допущением devops это админ, как и системный программист
                                                            –1
                                                            Проблема в том, что человек либо программист, либо админ. При совмещении мы либо получаем хорошего программиста с плохими админскими скиллами, либо хорошего админа с плохими программерскими скиллами. Нельзя быть где-то посередине.
                                                              –1

                                                              Можно, но крайне редко получается. Ну и программирование тогда системное в основном.

                                                                0
                                                                либо хорошего админа с плохими программерскими скиллами


                                                                No hire
                                                                  0
                                                                  «No hire» это такое типовое условие в договорах. Или вы о том, что хорошие админы не нужны?
                                                                    0
                                                                    что хорошие админы не нужны?


                                                                    Я думаю, что им определённо стоит задуматься о том, что бы получить хорошие кодерские скиллы — от знания алгоритмов, до базовых знаний в основных библиотеках, на которых пишутся аппликухи на рынке точно не помешают.
                                                                    Я вообще не представляю, как можно жить в cloud век без кодинга? У всех облачных окружений есть свои API, и обычные, классические админы их юзать не могут. Зачем они тогда нужны?
                                                                      0

                                                                      До cloud века в вашем понимании ещё далеко. Ну и многие cloud-провайдеры предоставляют те или иные морды к своим API. так что классические админы вместо отправки заявки хостеру на увеличение места на хранилище или поднятие нового виртуального сервера через треккер какой-нибудь, а то и по почте, делают это сами через предоставленную морду.

                                                                        0
                                                                        Даже в облаке чаще всего архитектура приложения со всеми его хостами спроектирована и нарисована заранее. Набор хостов создаётся один раз, с заранее прописанными объёмами диска, памяти и ядер.
                                                                        А автоматизация единоразовой задачи не нужна.
                                                                          0
                                                                          Даже в облаке чаще всего архитектура приложения со всеми его хостами спроектирована и нарисована заранее. Набор хостов создаётся один раз, с заранее прописанными объёмами диска, памяти и ядер.


                                                                          Что-то звучит утопично. В реальности всегда нужно затачивать облачное окружение под приложение.
                                                                          Это во-первых выгодно, а во-вторых всё равно же наняли девопса для того, что бы говорить с кодерами на одном языке — инопланетяне-админы, мыслящие не так, как кодеры, для команды пятое колесо.
                                                                            0

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

                                                                              0
                                                                              Одно из главных преимуществ облачных архитектур — простота масштабирования, которая подразумевает,


                                                                              Да, тыц-тыц, пара вызовов функций и в продакшен. Тыкать куда-то мышкой человеком, который не умеет в API, слишком долго и муторно
                                                                                0

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

                                                                                  0
                                                                                  Кто будет писать эти функции?


                                                                                  DevOps. У него хорошие скиллы в хай лоэд системах, ну если это миддл девопс :)

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


                                                                                  Я обычно использую связку Zabbix и Asterisk (практика показывает, что от СМС люди не просыпаются, зато от настойчивых звонков просыпаются. Дальше генератор речи festival)

                                                                                  создавать триггеры и на них вешать поднятие новых и опускание старых?


                                                                                  DevOps на лабе. Это часть сервиса, и infrastructure-as-code. Тот же Zabbix агент умеет применять на себя, на сервер, темплейты мониторинга.
                                                                                  А какие темплейты применять можно задать в переменных, в описании ноды в puppet/ansible
                                                                                    0

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

                                                                                      0
                                                                                      и их нужно минимум три, чтобы обеспечить нормальную скорость реакции на инциденты.


                                                                                      У меня другой опыт :( Увы :(
                                                                                        0

                                                                                        Доступны 24/7 без выходных и отпусков? Насколько дороже стоит согласие так работать вместо обычных 40 часов в неделю?

                                                                                          0
                                                                                          Где-то существуют IT компании в которых нет овертайм работы? серьёзно?

                                                                                          А вообще нужно просто писать код, который не падает, а ещё лучше, всё покрывать тестами, в т.ч. паппет код и ансибл плейбуками (jenkins наше всьо!)

                                                                                          Остаются криминальные случаи вроде DDoS, но с ними всё равно нужно бороться другими, специальными методами (а лучше вообще не попадать в криминальные ситуации)

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

                                                                                            Существуют компании, для которых овертаймы не норма, а реакция на форс-мажор. И существуют компании, которые понимают, что ни один, ни два человека не смогут обеспечить поддержку бизнеса 24/7. Три — доказанный практикой минимум, причём с запланированными овертаймами на случаи отпусков и болезней одного из трёх. Два — почти полная гарантия, что будет отсутствие реакции на инцидент (не решение, просто информация "взят в работу") по нескольку часов минимум. Один — отсутствие реации может быть и по несколько дней.


                                                                                            Всё тестами не покроешь. Особенно неисправности физической инфраструктуры или сравнимые с ними логические проблемы типа блокировки облачного провайдера каким-нибудь надзором.

                                                                                              0
                                                                                              Да, существуют. Я в такой работаю.
                                                                              0
                                                                              а то и по почте, делают это сами через предоставленную морду.


                                                                              Зачем они нужны? Их проще же для уменьшения разрыва между дев и оперейшенс уволить, а вместо них нанять девопса. Вырастет эффективность, и всё такое.
                                                                                0

                                                                                Один девопс вполне может стоить дороже трех админов, а полностью их заменить не в состоянии даже при работе 12/7, не говоря о 24/7.

                                                                                  0
                                                                                  Один девопс вполне может стоить дороже трех админов, а полностью их заменить не в состоянии даже при работе 12/7, не говоря о 24/7.


                                                                                  ОК, а почему у гугла только девопсы (SRE, как они их называют)? Скажите крупная контора, им можно? Ну так куча мелких стартапов нанимают одного девопса, которого 4 админа заменить не смогут (по тому, что 4 админа не будут лучше говорить на одном языке с Dev, чем один devops)
                                                                                    0
                                                                                    А где-то можно почитать подробности про то, как всё устроено у гугла? Что такое DevOps все понимают по разному, и многие пишут что это вообще не должность, а методика. Нет же должности «Аджайл», верно? Что такое это SRE в понимании гугла?

                                                                                    А крупные конторы могут позволить себе и неэффективную организацию. Примеров миллион.
                                                                                      0
                                                                                      А где-то можно почитать подробности про то, как всё устроено у гугла?


                                                                                      Я проходила интервью(не прошла) на SRE, они мне присылали материалы. Кажется, я не имею права их пересылать, но наверняка это всё выложено где-то на reddit.
                                                                                      0

                                                                                      Как эта куча мелких стартапов с одним девопсом решает проблемы 24/7? Три девопса или девять админов — можно пообсуждать что выгоднее. Три админа или один девопс — я бы не рискнул запускать проект с единой точкой отказа, даже если в обычном режиме девопс выгоднее.

                                                                                        0
                                                                                        Как эта куча мелких стартапов с одним девопсом решает проблемы 24/7?


                                                                                        Очень просто: они просто, обычно, не возникают ночью. А если возникнут, мониторинг позвонит(раз в полгода, и по списку всем членам команды, первому девопсу, второму тимлиду, а потом уже остальным) :)
                                                                                          0

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

                                                                                            0
                                                                                            Почему это ночью не возникают, если нагрузка плюс-минус равномерна за сутки


                                                                                            У меня такой опыт на основе информации по около десятку стартапов(в т.ч. знакомых, и двух, где я работала). Нагрузка обычно не равномерна — большинство пользователей из какого-то региона (например, Западная Европа или Северная Америка).
                                                                                              0

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

                                                              0
                                                              Обвязки уже есть, это системы оркестрации для облачных сред. Cloudify, Red Hat CloudForms, ManageIQ, IBM Cloud Orchestrator, HPE Cloud Service Automation, VMware vRealize и другие.
                                                                0
                                                                А не проще ли просто на configuration management tool написать что-то вроде своей «библиотеки», абстракции, и дальше деплоить абстрагировано?
                                                                Тем более что API часто похожи…
                                                                  0
                                                                  Вот в этом как раз и вопрос: где будем абстрагировать Cloud API — в Conf.mgmt. (для многих уже есть написанные библиотеки), или в Orchestration. Я делаю выбор в пользу оркестраторов, потому что они проще для конечного пользователя, и гибче для меня по функционалу. Там понятная система распределения доступов, и есть возможность быстрого построения кастомных порталов (service catalogue) для пользователей, отчёты (включая финансовые), алёртинг, и куча графиков. Config. mgmt. уже подвешиваю на post-deploy action.
                                                                  Config. mgmt. в качестве полного решения для IaaC я согласен использовать, но только когда это для одного проекта и с одним инженером (мною), который собирает всю инфраструктуру для приложения и разворачивает его только сам.

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

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