Блог

  • Почему появился DevOps?

    Почему появился DevOps?

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

    Методики и практики DevOps другие, сильно отличаются от методик работы системного администратора. Появление DevOps связано, в том числе, с появлением облачных сервисов, потому что в облаке другие подходы. Возьмем тот же ARM templates Azure. Resource management включает шаблоны, описывающие декларативную инфраструктуру. То есть современный админ должен уметь описывать, а не управлять работой сервера. Писать, что он хочет в виде шаблона, запускать его в облаке и идти пить кофе. И после этого вся инфраструктура будет развернута автоматически. Соответственно, там будет сформировано полное окружение, оно будет идемпотентным. Автоматизация автоконфигурирована: здесь есть скрипт, который все накатывает на поднятую машину и сам регистрируется. DevOps должен думать ресурсными группами, которые можно удалять, устанавливать, конфигурировать. DevOps – явление закономерное, так как декларативная модель находит свое применение и будет распространяться. Со временем системным администраторам придется осваивать инструменты DevOps.

  • Партнерская программа

    Партнерская программа

    партнерская программа

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

    – Привет, Вась, а кто поддерживает твой онлайн бизнес?

    – Я работаю с компанией “ИТ для бизнеса”, они решают все проблемы с ИТ сервисами.

    – Даш контакт?

    – Конечно!

    Компания ITFB приняла решение, поощрять такие рекомендации.

    Как работает партнерская программа?

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

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

    Какое вознаграждение Вы получите?

    • Если клиент пришел на регулярное обслуживание (администрирование серверов), то Вы получаете 15% от его первого платежа.
    • Если клиент заказал разовую ИТ услугу, то 15% от его платежа.
  • Облачный сервис Azure: Процесс миграции

    Облачный сервис Azure: Процесс миграции

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

    Стратегия миграции приложения

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

    Rehost

    Первый вариант помогает понять: готово ли приложение к облаку, какие инструменты получиться использовать и что нужно доработать. Этот вариант позволяет быстро развернуть ваше приложение в облаке. Он так же известен как «lift and shift». Приложение переносится так, как оно есть, без изменений кода.

    Преимущества: Можно быстро перенести инфраструктуру приложения и испытать ее в облаке.

    миграция в облако

    Для этого нужно скопировать ваши сервера с помощью Azure Site Recovery. Можно копировать как виртуальные машины, так и физические сервера. Облако включает в себя инструменты работы с разными базами данных. Инструмент миграции Azure Database Migration Service поможет в этом деле.

    Refactor

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

    По сути, этот вариант предлагает убрать из приложения все, что можно взять в облаке. Допустим, в приложении есть Active Directory. Так как в облаке есть свой сервис Azure Active Directory, обычный из приложения переносить не нужно, и можно использовать облачный. Тоже можно сказать о почтовых сервисах, SharePoint, файлообменниках и многих других, аналоги которых предоставлены в облаке.

    Rearchitect

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

     

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

    Проблемы с миграцией Баз Данных.

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

    Этапы миграции

    До начала миграции нужно оценить архитектуру приложения. Изучить производительность и проанализировать данные (в том числе анализ логов). Разобраться какие процессы обслуживания необходимы. До начала миграции не нужно «учесть всё». Облачные сервисы позволяют попробовать и испытать новые инструменты обратимо. На любом шаге можно вернуться назад. Исправить, доработать приложение или отказаться от внедрения.

    Rehost

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

    Есть два уровня этого этапа – Azure App service и Azure SQL Database. Для миграции SQL используем две утилиты – migration assistants. В результате получаем тот же сайт, написанный на ASP или dot NET и ту же базу данных, которая работает с SQL в облаке. IaaS поддерживает и другие типы баз данных, то есть у Azure есть для этого сервисы

    Rebuild

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

    перенос в облако

     

    Можно добавить в приложение облачный storage, cash, очереди и так далее. Получаем двухуровневое приложение в стиле Azure, наш web-application service.

    Из него можно убрать постепенно ненужные вещи, которые не предоставляют услуг пользователям. Изменить backend в виде очередей. Добавить storage – чтобы весь контент получать через Content Delivery Network. Подключить redis cash, чтобы запросы кэшировались и база не дергалась лишний раз. Теперь это уже рабочее приложение.

    Rearchitect

    Меняем приложение – меняем сущность приложения и код. Цель – сделать приложение быстрым, экономичным и отказоустойчивым. Добавляем traffic manager, добавляем второй регион, который будет реплицировать static content, queues, базы. Но идея Azure – отказоустойчивое приложение, которое будет обслуживать пользователей в разных регионах.

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

    Результат.

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

    Наша компания имеет большой опыт миграции решений в облако, обращайтесь, office@itfb.com.ua

  • CloudFlare в помощь! 4 шага для доступа к веб-серверу

    CloudFlare в помощь! 4 шага для доступа к веб-серверу

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

    Популярные варианты защиты веб-сервера

    Защищать веб-сервер – дело нужное. Уже разработано и опробовано множество практичных способов мер предосторожности. Например, на городить редиректов.
    Оптимальный вариант – сделать открытым http/https-трафик только для адресов защитного прокси конкретного веб-сервера. Хотя и этот вариант возможно окажется бесполезным, если вступят в действие сайты такого рода, как crimeaflare.org.
    Пользуется популярностью многоходовое решение, ведущее к тому, чтобы никто не узнал, что же размещается на вашем IP: 1. по закрывать все порты на сервере → 2. отключить ICMP → 3. доступ сделать только через IPMI/VNC.
    А если для этого использовать iptables? Пробуем!

    CloudFlare: как разрешить доступ к веб-серверу в 4 шага?

    Большое число адресов CloudFlare сжимаются в сравнительно маленькое число подсетей. На официальном сайте CloudFlare можно отыскать и воспользоваться актуальными подсетями, рекомендациями от профессионалов про iptables. Здесь возникает неудобство: все предлагается делать вручную. К тому же это ненадежно. Объясняем: со временем адресация на CloudFlare может изменяться. Не нужно исключать ситуацию, когда на вашем сервере просто будет поставлен запрет прокси на новых адресах. Как итог – результат неутешительный. Пользователи не смогут посетить ваши сайты, потому что сессии должны проводиться через новые адреса прокси.
    Все можно решить. К тому же все обустроить так, что доступность веб-сервера будет автоматизирована. Предлагаем пошаговый алгоритм для iptables.

    Шаг №1. Изначально следует запретить трафик (весь! И http, и https).

    Шаг №2. Положить в какой-нибудь скрипт. Это может быть cloudflare-update.sh по /root/cloudflare-update.sh со следующим содержимым:

    Подробнее:

    • удалить уже имеющиеся записи, которые появлялись раньше;
    • добавить все данные CloudFlare, прописанные в списке адресов.

    Нам такая процедура поможет избежать дублирования правил. Не забудьте основное – сохраниться!

    Шаг №3. Необходимо сделать скрипт действующим.

    Шаг №4. Осталось добавить очень важное задание – регулярное обновление адреса (оптимально через двенадцать часов). Прописать в крон можно, к примеру, в конец файла /etc/crontab.

    Итоги

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

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

  • Администрирование внутренних требований к IT продуктам компаний

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

    • Докопаться до сути. Когда поступает какое-либо требование, идея или проблема, то почти всегда это в разобранном виде и оно требует реализации таким способом, что нужно перестроить все для решения какой то задачи. Нечто не совсем корректное и требующее основательной доработки. Для того, чтобы не погрузиться в хаос, необходимо понимание, что стоит за этими предложениями и проблемами и какая именно задача требует решения.
      Не всегда это очевидно и требуется уточнение одинаковой информации под разным углом, пока не станет понятно, что по существу требуется и какую реально проблему следует решать. Часто понимание, к которому пришли отличается от первоначального вида, но иначе невозможно решить проблему. Вот это понимание сути проблемы и есть первый шаго на пути к ее решению.
      Еще один момент: правильное восприятие самих некорректных требований. Следует принимать как нормальное явление и то, что будут трудности с формулировкой истинной проблемы и следует поработать с ее конкретизацией. Дело не в наличии каких-либо проблем, а в умении работать с ситуацией.
    • Идеи, которые уже реализованы. Один из простейших вариантов, когда проясняется, что решение задачи уже разработано и имеется в наличии. Конечно, его вид может потребовать каких-либо доработок. Либо работник не был информирован о наличии такого решения. Для решения этой задачи требуется донести информацию пользователю для получения результатов, используя то, что уже имеется.
    • Задачи, которые повторяются. Поступают задачи, различающиеся несколькими моментами. Их можно объединить для построения единого решения, удовлетворяющего всех либо имеющего различные вариации, чтобы создать один раз систему или её часть, которая решит все задачи сразу. Даже если эта система будет с различными настройками под каждое решение. Если подобные поступающие задачи отправлять в разработку сразу, то получим множество копий решений с небольшими изменениями в логике и все изменения будут происходить по сути в одной системе.
    • Векторные требования. Возможна ситуация, когда две задачи противоречат друг другу либо их невозможно совместить. Для выхода из ситуации требуется дойти до корня проблемы и выявить то, что действительно необходимо и устранить противоречие. Возможно найти непересекающиеся варианты решений либо одно из требований решить другим способом, более простым и эффективным. Тогда оказывается, что требование находит решение либо трансформируется в другое – непротиворечивое.
      Любую задачу можно решить несколькими вариантами. А если взять сырую проблему-требование и поработать с ней, выявить то, что находится в ее принципе, тогда возрастает и число решений. А чем больше решений, тем проще подобрать такие, которые никак не мешают друг другу и наоборот могут помочь.
    • Общая картина происходящего. Здесь идея в том, что все идеи и задачи стекают воедино и выстраивается общая схема происходящего. Можно анализировать и систематизировать для разработки рациональных действий, брать и реализовывать в необходимом порядке, брать и обрабатывать (доводить до состояния корректных) Получится общая картина – верный путь к тому, чтобы получить готовые к разработке задачи. Задачи, которые могут не быть тем, чем были изначально. Задачи, которые решат сразу ряд требований или будут частью масштабного проекта.
  • Как добиться эффективного пайплайна CI/CD на практике?

    Конвейер Continuous Integration и Continuous Delivery или CI/CD-пайплайн представляет собой целую цепочку процессов. В нее последовательно включено несколько сервисов – Portainer, Jenkins, Docker Swarm, Ansible. Как это удалось осуществить на практике? В статье мы рассмотрим реализацию такой цепочки на проекте IT-команды Уральской Дирекции.

    Как определяются цели?

    Чтобы эффективно реализовать проект, первоначально нужно разобраться, чего ожидают от него заинтересованные стороны – бизнесмен-заказчик и IT-команда. Не секрет, что деловые люди стараются заработать как можно больше в максимально короткие сроки, поэтому ждут быстрого вывода готового продукта на рынок. Исполнители – это команда из двух разработчиков и одного админа, видят перед собой иные цели. У разработчиков на первом месте не финансы, а творческий подход, подтвержденный реальным результатом. Админ же, в свою очередь, стремится обеспечить качественный сервис, придерживаясь методологии DevOps в соответствии с принципами CI/CD (как заявлено в этом проекте). Вывод: поможет организация пайплайна, который охватит все этапы работы вплоть до запуска продукта для завершающего тестирования.
    Командная работа началась с обсуждения выбора системной архитектуры. Определились на двух ее основных составляющих:

    • бекэнд на Java (реализация с помощью фреймворка Spring Boot);
    • фронтенд на NodeJS (с NGINX-сервером, который распределяет между приложением и инфраструктурными составляющими системы запросы) + ReactJS.

    Техническая задача IT-команды на начальном этапе – подготовить оборудование для эффективного пайплайна CI/CD, поэтому конвейер будет выглядеть, как цепочка определенных операций:

    публикация разработчика коммита в git →
    тестирование git полученного коммита (наличие верного формата, сопоставимые стили оформления и т.д.) →
    web-hook механизм сервера git задействует Jenkins, за тем последует скачивание исходников для запуска конвейера.

    Здесь свой порядок действий:
    компиляция →
    тестирование исходников →
    сборка очередного варианта Docker-образов →
    их публикация в специальной системе Artifactory →
    перезапуск полученного варианта продукта на сервере.

    При неудачном обновлении всегда можно выполнить откат до предыдущей версии.

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

    Об установке и базовых настройках на хост-системе

    В ходе реализации поставленных задач IT-команда решила воспользоваться Ansible. Это позволило добиться автоматизации всего конвейера хост-системы по максимуму, ее качественного функционирования всего в три этапа.
    Начальный – ssh HostKeyChecking. Нужен для проверки ssh-отпечатка удаленного конфигурируемого хоста. В этом режиме отключается авторизация с помощью пароля, поэтому предполагается несколько вариантов решений:

    • в local cash добавляется ssh-отпечаток (например, в ansible.cfg дописать host_key_checking, чтобы отключить проверку полностью, либо выполнить определение специальной переменной окружения – для приостановления проверки).
    • отключение HostKeyChecking.

    Второй этап – Inventory. Предполагает описание тех хостов, конфигурациями которых нужно управлять. Для этого предлагается два формата – либо yml, либо ini. Выбрали формат yml.
    Третий – Playbook. Из Inventory описывается декларативно итоговое состояние хостов в начальном формате (здесь yml) и полная настройка базовой системы, предполагающая создание пользователей, установку Docker.

    Какие сервисы можно использовать?

    Одним из полезных сервисов оказался Jenkins CI. Он необходим для деплоймента и Continuous Integration. Необходимо обратить внимание на ряд ключевых моментов:

    • каждый образ получает свою метку-тег (очень помогает при откате неудавшегося приложения);
    • таски-пайпланы – декларативные, скриптованые (на Groovy Script – задачи, в git – код с исходниками);
    • в Docker-контейнере Jenkins запускает playbook-код Ansible, а на local-машине временно сохраняется пароль (файл для этой операции – initialJenkinsAdminPassword.txt).

    Еще один нужный сервис – Portainer. Он отличается легким развертыванием и высокой производительностью. Но в нашем случае использовался Docker Compose, который по своим функциям и оркестрации подходит для 1 хоста. Так, сервисы запускались с помощью docker-compose.yml, но со своими особенностями.
    1 особенность – отсутствие упоминаний о бекэнде и фронтенде.
    2 особенность – есть на внешнюю сеть int-ссылка (здесь под внешними ресурсами понимают те, которые нигде не упоминаются).
    Описываемая цепочка требовала рестарта сервисов, чтобы обновлялись варианты образов в репозитроии Docker – Artifactory. Такие функции уже встроены в Docker Swarm. Это и позволяет изменять отобранные образы. Рестарт автоматически запустится, если в репозитории будет новая версия продукта. В противном случае, продолжится выполнение прописанного сценария.
    Для сохранности сетевой связанности компонентов Docker Swarm с сервером NGINX создали кластерную сеть-Overlay. В нее включены не только перечисленные сервисы, но и компоненты приложений.

    Выводы

    На первом этапе IT-команда исполнителей планировала добиться всех выгод от DevOps. Для этого требовалось организовать цепь операций по непрерывной доставке кода от git до сервера. В результате запущенного пайплайна и продуманных действий системная архитектура была реализована в течение двух недель.

    Грамотно продумать и реализовать каждый этап CI/CD-пайплайна вам помогут здесь.

     

  • О чём забывают, выбирая между “железом” и “облаком”

    О чём забывают, выбирая между “железом” и “облаком”

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

    И если в этих вопросах облака давно лидируют, то в плане стоимости по-прежнему возникает много разночтений. Причем основным аргументом, который выдвигают поклонники собственной аппаратной составляющей, является стоимость, рассчитанная “в массе”, без учета нюансов. Как раз эти нюансы, которые оттягивают на себя финансовый, материальный и виртуальный потенциал предприятия, мы и рассмотрим в статье. А заодно поможем вам сделать объективный вывод

    Обеспечение отказоустойчивости

    Cloud-проекты априори предусматривают наличие соответствующего уровня отказоустойчивости, благодаря кластеризации виртуальных серверов и автоматической резервации минимальных запасов, нужных для защиты данных. Таким образом, ресурсы могут “безболезненно” перемещаться на резервный хост для проведения на основном хосте регламентных работ, или по случаю его отказа.

    Причем, такая услуга не потребует дополнительной оплаты. В стоимость виртуального диск-пространства заранее включены типы рейдов, а также резервные носители, устойчивые к множественным отказам. Если же используется своя разработка для сохранения и обработки данных, то ей будут доступны от 45 до 65 процентов “сырого” объема диска в зависимости от избранного типа RAID-массива.

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

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

    Пределы серверной и СХД загрузок

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

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

    Полная утилизация доступных объемов, полученных вследствие сборки RAID-массивов, также не представляется возможной. Так как требуется резерв размером в 10% и выше от всего доступного для адресации пространства, чтобы обеспечить полноценное функционирование стораджа.

    В случае хранения информации на мех.дисках и при интенсивной дисковой загрузке не стоит заполнять размеченные луны свыше 70-80%, так как это приведет к деградации производительности хранилища. Что касается all-flash стораджей, то они все еще довольно дорогостоящие. Их приобретение для многих организаций является нерентабельным, даже с учетом того, что SSD-диски не испытывают проблем, описанных выше.

    Издержки из-за ограниченного масштабирования

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

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

    Высокая конкуренция на B2C рынках обуславливает столь же высокие требования к активности и оперативности при запуске и продвижении новых продуктов или услуг. Зачастую в таких условиях уже второй по активности “игрок” получает существенные убытки вместо прибылей, а тот, кто успевает вовремя среагировать на вызовы рынка, выдерживает нужный темп – получает все.

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

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

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

    В то же время, для наращивания собственной архитектуры понадобится минимум 2-3 месяца, которые уйдут на расчеты, поставки, монтаж и эксплуатационные настройки. И это при условии соблюдения принятых стандартов, с учетом налаженных процессов расчета конфигурации в определенном вендоре.

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

    Издержки при неточной оценке объемов ключевых систем

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

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

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

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

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

    Обслуживание инфраструктуры

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

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

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

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

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

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

    Вендорная поддержка рабочего ПО и тех.оснащения

    К сожалению, нет ни одного, даже самого авторитетного производителя аппаратуры и ПО, который мог бы гарантировать 100% отсутствие брака. Самый худший (и не такой уж редкий) вариант последствий – когда отказывает не просто часть сервиса или его функционала, а вся система. Как правило, устранение проблемы, возникшей из-за производителя, требует времени даже в том случае, если вы уплатили за комплексный сервис с гарантированной, максимально оперативной поддержкой.

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

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

    Возведение и содержание серверной

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

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

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

    Среди таких затрат – проектирование и постройка помещения, прокладка инженерных линий, подключение внешних каналов связи, установка стабилизирующей и защитной аппаратуры для компенсации пиковых нагрузок, отказов и отключения энергопитания (ИБП), организация охлаждения и вентиляции, интеграция СКУД, сигнализации и средств пожарной безопасности. Причем, в идеале все инженерные комплексы требуют дублирования для повышения отказоустойчивости и компенсации возможных рисков.

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

    Конечно, есть менее затратный выход – размещение комплекса в коммерческом центре обработки данных. Однако клиенты, оценившие преимущества cloud-сервисов, быстро переходят к гибридным программам, а потом и вовсе заменяют большую часть соответствующей инфраструктуры cloud-решениями, отдавая “освобожденную” аппаратуру под другие задачи.

    Выводы

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

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

  • Переход к управляемым и смена Standard на Premium

    При переходе от неуправляемых дисков к управляемым существует ли способ перейти от версии Standard к Premium?

    Управляемые диски позволяют не беспокоить­ся об учетных записях хранилища и ограничениях, с ними связанных. Вместо этого диск становится пер­воклассным ресурсом Azure. Очень просто конверти­ровать неуправляемый диск в управляемый с помощью команды ConvertTo-AzureRmVMManagedDisk. Вы можете подключиться к такому же типу, то есть от версии Standard неуправляемых дисков перейти к версии Standard управляемых дисков. Если вы хотите выполнить переход от версии Standard неуправляе­мых дисков к версии Premium управляемых дисков, вам нужно выполнить следующие шаги:

    1. Убедитесь, что виртуальная машина была тако­го типа, который поддерживает версию Premium, а именно <pecypc>S (DS, FS, GS и т.д.).
    2. Завершите работу виртуальной машины.
    3. Измените виртуальную машину на использова­ние управляемых дисков по команде ConvertTo- AzureRmVMManagedDisk.
    4. После запуска виртуальной машины поменяй­те управляемый диск с версии Standard на версию Premium в свойствах диска.
    5. Перезагрузите виртуальную машину.

     

  • Вакансия Linux администратор

    В нашу команду требуется системный администратор, с опытом работы Linux ОС.
    Удаленная работа.
    Опыт от 2х лет.
    Работа: 4-7 часов в день.

    Тестовое задание для кандидата администратора Linux

    1. Процесс миграции сайта с сервера на сервер с минимальным простоем (описать варианты)
    2. Возможные варианты работы php с веб серверами Apache и Nginx? основные отличия ?
    3. Что это такое <? ?> Включино ли оно по умолчанию?
    4. Какую файловую систему вы бы выбрали для файлового сервера? Почему?
    5. Организация почтового сервера. Какие службы используются и какие задачи выполняют.
    6. SSL сертификаты. Зачем нужна цепочка сертификатов.
    7. Что такое sysctl.conf
    8. Что такое rc.local

    Так же прошу вас создать у себя виртуальную машину с Centos7, параметры машины – 1гб озу и 1 процессор.
    Необходимо сразу оптимизировать работу Машины для LAMP стэка. Возможно использовать php-fpm, и percona.
    Конфигурации ОС, DB, и т.д. необходимо будет продемонстрировать.

    Как только вы закончите с машиной – пожалуйста пишите в скайп – vkarabedyants, Представляйтесь что вы по вакансии и показывайте ответы на вопросы. + доступ к машине.

  • Azure Key Vault и PowerShell

    Как я могу создавать и читать секретную информацию в Azure Key Vault, используя PowerShell?

    Недавно я попытался поработать с Azure Key Vault, используя команды PowerShell. Мне хотелось сохра­нить особый пароль в Key Vault, который впоследствии мог бы использоваться сценарием (обратите внимание, что на практике я бы спрятал ACL в хранилище клю­чей, чтобы ограничить его применение, и, может быть, к нему был бы доступ только зарегистрированному приложению, причем так, чтобы оно могло только читать его). Пример приведен в листинге.

    Листинг. Работа с Azure Key Vault

    #Create a new vault that supports HSM-protected keys (premium) New-AzureRmKeyVault -VaultName SavillVault' -ResourceGroupName RG-SCUSA' -Location 'South Central US' -SKU Premium #Create a new secret
    Ssecretvalue = ConvertTo-SecureString Pa55wordT0p -AsPlainText -Force
    #Store the secret in Azure Key Vault
    Ssecret = Set-AzureKeyVaultSecret -VaultName 'SavillVault' -Name 'JohnPassword -SecretValue Ssecretvalue
    #Look at the URL and value Ssecret.Id
    Ssecret.SecretValue #Get the secret text
    (Get-AzureKeyVaultSecret-VaultName SavillVault' -Name JohnPassword).SecretValueText