То, что они могут, не означает, что они должны это делать. Конечно, ваши разработчики обладают навыками работы с облачной инфраструктурой, но является ли это отличной идеей?
Короткий ответ... ну, нет. Слишком часто, однако, это то, что мы видим после первоначального построения облака.
Честно говоря, я уверен, что многие начинающие с удовольствием берут на себя эту ответственность на начальном этапе - это понятный инстинкт. Независимо от того, являетесь ли вы начинающим или малым предприятием, впервые мигрирующим в такую среду, как Amazon Web Services (AWS), после того, как инфраструктура будет готова, возникает желание взять ее в свои руки и взять управление под свой контроль.
И, в течение короткого периода времени, это может быть неплохо. Но, по мере роста компаний, вы начинаете понимать, почему это не может работать в долгосрочной перспективе. Есть несколько причин, почему это так.
1) Это отвлекает внимание.
Во-первых, вы не хотите, чтобы ваша инфраструктура была основным направлением деятельности для разработчиков. И, попросив их запустить инфраструктуру в дополнение к другим задачам, вы будете отрывать их от приоритетных проектов.
Если вы хотите повысить эффективность любого бизнеса, вы захотите, чтобы ваши разработчики сосредоточились на кодировании функций, которые позволят улучшить ваш продукт - и дифференцировать ваш бренд.
Что касается разработок, то это стремление к улучшению должно превзойти более общие задачи поддержки, такие как мониторинг времени отклика на запросы, которые могут выполняться внутренней или внешней службой поддержки.
2) Вы вводите риск
Также не имеет смысла разделять внимание, если одна задача может иметь прецедент над другой. Существует вероятность того, что ваша инфраструктура станет второстепенной, и ею будут пренебрегать. Это увеличит опасность простоя в какой-то момент в будущем, что навредит бизнесу.
Этот риск отвлечения внимания действительно усиливается, когда компании быстро растут. Мы часто видим, что это происходит, например, когда стартапы являются получателями финансирования инвесторов. По мере того, как компании наращивают свои амбиции, ресурсы растягиваются - так как может потребоваться время, чтобы набрать команду с нужными навыками, чтобы продвинуть бизнес вперед. Опять-таки, это может затруднить для разработчиков уделять внимание управлению инфраструктурой.
Когда быстрый рост происходит органически, например, после завоевания клиента крупного предприятия, проблемы, которые это создает, могут быть еще хуже. Эти контракты обычно поставляются с множеством специфических SLA, охватывающих такие вещи, как гарантированное время безотказной работы - и необходимость сосредоточиться на инфраструктуре добавит большую нагрузку на разработчиков.
3) Вы быстро достигнете критической точки.
Когда компании развиваются подобным образом, нечестно постоянно просить разработчиков нести ответственность за инфраструктуру, особенно когда требуется круглосуточный мониторинг и реагирование на происшествия. Они никогда не смогут удовлетворить эти требования без помощи специальной группы поддержки.
Это момент, когда у организаций не остается другого выбора, кроме как либо инвестировать в специальную внутреннюю группу поддержки, либо передавать свои требования по поддержке поставщику управляемых услуг. Учитывая расходы, связанные с наймом, обучением и содержанием квалифицированной команды инженеров, компании обычно предпочитают прибегнуть к аутсорсингу на данном этапе.
4) Вам определенно понадобится поддержка
В любой момент, когда вы понимаете, что существует необходимость в аутсорсинговой поддержке, важно рассмотреть три основных доступных варианта. Во-первых, вы можете обратиться за помощью к поставщику услуг общего назначения, который предлагает услуги компьютерного облака как вариант. Во-вторых, вы можете нанять специалиста по компьютерному облаку, чтобы предложить экстренную услугу "исправление неисправностей". В-третьих, вы можете нанять специалиста по облаку для предоставления проактивной поддержки.
Всегда предпочтительнее обращаться к специалисту, а не к специалисту общего профиля. Но, учитывая, что специализированная поддержка инфраструктуры компьютерного облака является относительно новой областью, а специалистов не так уж и много, у некоторых возникнет соблазн выбрать последнее.
Недостатком является то, что это не гарантирует наличие необходимого опыта - а когда речь идет о внедрении облачных технологий, способных увеличить скорость выхода на рынок и повысить операционную эффективность, то вам нужен партнер, который досконально разбирается в ландшафте.
Вы также захотите, чтобы этот партнер был активным. Проблема с билетными системами "break-fix" заключается в том, что вы будете только заштукатуривать трещины; вы не собираетесь улучшать эксплуатационную производительность.
5) Посвящение - это то, что вам нужно.
В идеале, ваш партнер по аутсорсинговой поддержке должен имитировать поведение внутренней команды. Они бы не сидели сложа руки, если бы можно было добиться улучшений - они бы принимали меры. Это жизненно важно, поскольку облачные инфраструктуры с технической поддержкой развиваются так быстро. Постоянно появляются новые инструменты, которые позволяют нам быстрее внедрять улучшения и создавать более эффективные способы работы.
В этом отношении проактивный поставщик управляемых услуг может фактически обеспечить экономию, которая высвобождает бюджет для других проектов. Им также потребуется время, чтобы понять, как растет ваша компания, и создать дорожную карту усовершенствований, которая позволит компании достичь своих амбиций.
Однако, если у вас нет специальной команды поддержки, и вы просите разработчиков покрыть эту роль поддержки в дополнение к их другой работе, вы вряд ли поймете эти преимущества. Гораздо лучший подход заключается в том, чтобы позволить разработчикам сосредоточиться на тех областях, где они приносят наибольшую пользу, и работать со специалистом, который будет не только предлагать поддержку на уровне соглашения об уровне обслуживания, но и улучшать производительность вашей инфраструктуры.
