Милі та пухнасті

Category: Uncategorized

  • 5 лучших советов FinOps по оптимизации затрат на облако

    Эффективность, гибкость и стратегическая ценность облачных вычислений побуждают организации быстро развертывать облачные решения. Fortune Business Insights прогнозирует, что мировой рынок облачных вычислений будет расти почти на 18% в год до 2028 года.

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

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

    1. Ресурсы тегов

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

    2. Обязательства по плану сбережений

    Если организации знают, что они будут использовать AWS в следующем году или около того, у них нет причин не воспользоваться планами AWS Compute Savings Plans. Планы позволяют подписчикам платить меньше в обмен на обязательство использовать определенные сервисы AWS в течение одного-трех лет. Экономия за счет обязательств может достигать 50 %, поэтому даже при недоиспользовании ресурса на 10–20 % вы все равно получаете значительную экономию. Аналогично в Azure – технология резервирования ресурсов от года до трех, которая позволяет экономить.

    3. Частные цены

    AWS предоставляет частные цены на различные услуги. Наиболее распространенными являются Cloudfront, Data Transfer и S3. Вы можете иметь право на использование: более 10 терабайт для исходящей передачи данных Cloudfront, 500 терабайт для межведомственной передачи данных, 500 терабайт для исходящей передачи данных или петабайт S3 в месяц. Если это относится к вашей организации, предлагаем вам поговорить с вашим менеджером по работе с клиентами AWS о значительной экономии, которую вы можете получить за счет частных цен.

    4. Не игнорируйте меньшие затраты

    На 10 основных облачных сервисов организации обычно приходится от 70% до 90% общих затрат на облако. Но мы призываем не игнорировать более мелкие службы. Для услуг, которые стоят от 100 до 1000 долларов в месяц, все же стоит получить представление о каждой из них, чтобы определить, есть ли забытые резервные копии, которые больше не нужны, или тестовые среды, которые не используются. Эти небольшие выигрыши могут составлять до тысяч долларов в день.

    5. Быть в курсе

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

    Добейтесь успеха с FinOps 

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

  • Devops или нет 7 признаков

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

    1. Раздельное размещение DevOps

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

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

    2. Сосредоточение внимания на инструментах, а не на людях

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

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

    Внедрение DevOps — это итеративный процесс, поэтому ИТ-директор должен начать с оценки текущего состояния команды разработчиков, а затем постепенно выстраивать стратегию постоянного совершенствования с участием людей, процессов и инструментов, которые могут развиваться вместе с будущими потребностями и разработками. «В конечном счете, креативность — это мышца, которую нужно постоянно тренировать, чтобы расти», — отмечает Кумар.

    3. Слишком мало автоматизации

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

    Прежде чем продвигать инициативу по автоматизации, внимательно изучите потребности разработки, существующие контракты и текущие проектные группы. «Посмотрите, находятся ли навыки организации на том уровне, на котором вы можете автоматизировать инфраструктуру, — говорит Ян Фогарти, управляющий директор по технологиям и операциям консалтинговой фирмы Accenture Federal Services.

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

    4. Бессистемная автоматизация

    Хотя автоматизация очень полезна, многие организации переходят на автоматизацию DevOps без достаточного анализа и планирования. «Мы видели организации, которые отдавали приоритет автоматизации, не принимая во внимание другие аспекты, включая управление, людей, процессы и технологии», — говорит Аарон, управляющий директор DevSecOps в Deloitte Risk & Financial Advisory. Такие организации обычно тратят значительное количество времени на пересмотр и исправление работы по автоматизации.

    Прежде чем перейти непосредственно к автоматизации, Аарон предлагает установить надежное управление и стандартизировать требования и процессы. «Сотрудничество между бизнес-подразделениями — неотъемлемая часть DevOps, — отмечает он. Устраните любые организационные барьеры, которые могут существовать. «Руководство руководства будет важно для того, чтобы задать тон», — говорит О. «Кроме того, используйте интеллектуальные инструменты оркестрации, чтобы помочь еще больше устранить разрозненность и обеспечить эффективную связь».

    5. Вынашивание нереалистичных ожиданий

    Старшие технологические лидеры должны сосредоточиться на обязательствах, выходящих за рамки простого внедрения новых технологических инструментов и методов. «Они должны уделять приоритетное внимание меняющейся культуре и мышлению сотрудников», — говорит Тим ​​Поттер, директор Deloitte Consulting. «Они также должны установить реалистичные сроки, чтобы трансформация укоренилась в организации».

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

    Технологические лидеры также должны быть готовы принять тот факт, что после перехода на DevOps производительность может сначала снизиться, прежде чем она улучшится. «Они должны быть готовы обеспечить «прикрытие» для своих прикладных групп, что позволит им протестировать и научиться работать с новой моделью», — советует Поттер. «Завышенные ожидания и отсутствие достаточного времени для трансформации может привести к тому, что организации будут принимать DevOps только номинально».

    6. Команды, застрявшие в прошлом

    Старые привычки умирают с трудом. В течение десятилетий разработка программного обеспечения следовала традиционной методологии водопада, процессу, который требовал заблаговременного сбора требований, создания функций и, наконец, передачи результатов QA и другим командам для выпуска, говорит Ашиш Какран, директор венчурной ИТ-компании Thomvest. Предприятия. «Раньше требовались месяцы, прежде чем клиенты увидели какие-либо новые функции», — отмечает он.

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

    Какран предполагает, что быстрый и простой способ выявить борющуюся команду — это изучить их DevOps «Epics» и «Stories».

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

    7. Негибкость

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

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

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

    Достижение баланса

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

    Помните, однако, что преимущества будут ограничены и отсрочены, если вся организация не примет трансформацию. «Неизбежно возникнут взаимозависимости, которые затормозят команду разработчиков, если более широкая организация не изменит ситуацию», — говорит Поттер.

  • Иностранные ИТ-специалисты смогут открывать бизнес и платить налоги в Украине

    В октябре 2022 года президент подписал законопроект № 5270 , предусматривающий введение института электронного резидентства и регулирующий налогообложение этой категории предпринимателей. Закон вступит в силу с 1 апреля 2023 года.

    Контекст

    Налоговый кодекс Украины не содержит понятия «е-резидент», а также не устанавливает специальных правил налогообложения доходов е-резидентов, порядка проведения проверок.

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

    ℹ️ Что смогут делать е-резиденты:

    ✔️ осуществлять предпринимательскую деятельность (ФЛП);
    ✔️ дистанционно открывать и управлять банковскими счетами;
    ✔️ пользоваться современными инструментами для управления бизнесом онлайн;
    ✔️ подписывать документы электронной подписью.

    ℹ️ Налогообложение

    Е-резидент становится плательщиком единого налога третьей группы. Это предполагает уплату 5% дохода (если оборот не превышает лимиты для ІІІ группы ФЛП) и 15% (если лимиты превышены).

    ℹ️ Как получить статус е-резидента:

    ✔️ зарегистрироваться на портале или в приложении «Дия»;
    ✔️ пройти проверки безопасность;
    ✔️ получить электронную цифровую подпись;
    ✔️ открыть счет в банке (избранный банк будет налоговым агентом е-резидента).

    ℹ️ Кто НЕ может быть е-резидентом:

    ⛔️ граждане Украины;
    ⛔️ иностранцы, имеющие право на постоянное проживание в Украине или являющиеся налоговыми резидентами Украины;
    ⛔️ лица без гражданства;
    ⛔️ лица, получающие доходы в Украине за товары, работы, услуги (кроме пассивных доходов);
    ⛔️ граждане государства, признанного агрессором и/или оккупантом в отношении Украины.

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

    Напомним, военный 2022 год отметился законами и постановлениями, касающимися IT-отрасли: Дия City, е-резидентство, обращение криптовалют и т.д.

  • Как выбрать облачного провайдера для реляционной базы данных – сравним Azure и AWS

    Как выбрать облачного провайдера для реляционной базы данных – сравним Azure и AWS

    Общий обзор реляционных баз данных Azure и AWS

    Ниже есть общая таблица, основываясь на ней, мы видим, какие СУБД представлены в облаке как сервисе (SaaS).

    saas сервисыПредставление реляционных баз данных в облаках

    СУБД в AWS представлены в рамках единого сервиса RDS

    На самом деле, при создании экземпляра базы данных в RDS (relational data service) вы будете встречать особенности конкретных СУБД, а не общего сервиса RDS.

    То есть, если вы разворачиваете MS SQL Server, вам необходимо выбрать тип лицензирования — Enterprise, Standard, Express или Web edition, выбрать версию (2012-2019), диски и мощности виртуальной машины, на которой будет развернут экземпляр, и сконфигурировать инфраструктуру. Если работа будет с другими видами СУБД, то соответственно все конфигурируется под конкретную СУБД со всеми ее особенностями.

    Таким образом, RDS в большинстве своем повторяет и реализует полноценные СУБД, и при выборе и настройке пользователи руководствуются знаниями о наземных полноценных реализации.

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

    СУБД в Azure выделены в отдельные сервисы

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

    Способность к масштабируемости обусловлена ​​тем, что управление инфраструктурой в большинстве сервисов СУБД полностью выносится на уровень ответственности Microsoft, а на уровне пользователя остается только управление данными и приложением.

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

    cloud service

    Облачные сервисы СУБД в Azure имеют свои подходы, поддерживают полную совместимость кода, но не обеспечивают полной совместимости с полноценной версией СУБД, проекцией которой они являются.

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

    Условно говоря, функционал MS SQL Server в облаке может быть разделен на отдельные услуги, обладающие собственными принципами ценообразования.

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

    Azure MS SQLПример: Гранулярность – неисчерпаемое количество возможных сервисов и факторов ценообразования.

    Кроме того, Azure имеет более широкую линейку предложений вариантов баз данных, относящихся к типам СУБД MS SQL server. На самом деле это неудивительно, поскольку Azure – это Microsoft, и SQL server – это тоже Microsoft.

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

    При этом все равно многие административные вопросы будут оставаться на стороне Microsoft.

    Многое то, что умеет делать RDS с базами данных SQL server, будет уметь и Azure, но дополнительно он будет предлагать еще больше гибридных версий под разных пользователей и под разные кейсы.

    Предлагаю подробнее рассмотреть предложения Azure и AWS.

    Что предлагает Microsoft в рамках Azure SQL

    azureМодели развертывания в Azure SQL

    Что предлагает AWS

    Реляционная база данных – это виртуальная машина с установленным MS SQL Server. SQL Server on Azure Virtual Machines – это тождественные сервисы (IaaS).

    Далее AWS предлагает упоминаемый RDS из MS SQL Server (SaaS).

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

    Опять же, Azure также дает возможность тонко подходить к вопросу.

    Azure имеет managed instance, тип Azure SQL, наиболее соответствующий RDS, где также выбирается виртуальная машина. Нужно понимать ее особенности и конфигурационные детали, но дополнительно Azure SQL single database, действительно работающая как услуга, наиболее очищена от инфраструктурных вопросов и является «чистым» database engine.

    Azure AWS
    Виртуальные машины (IaaS) MS SQL Server on VM MS SQL Server on EC2
    Услуги (SaaS) (Hybrid) Managed Instance MS SQL Server на RDS
    Услуги (SaaS) Azure SQL Single Database

    При этом обеспечивается стандарт T-SQL для всех версий.

    Например, варианты выбора параметров виртуальной машины (ec2) для RDS.

    Name Instance Type Memory Storage Processor vCPUs Network Performance Arch
    M1 General Purpose Medium db.m1.medium 3.75 GiB 1×410 intel Xeon Family 1 vCPUs Moderate 64-bit
    M1 General Purpose Small db.m1.small 1.7 GiB 1×160 intel Xeon Family 1 vCPUs Low 64-bit
    M3 General Purpose Medium db.m3.medium 3.75 GiB 1×4 SSD Intel Xeon E5-2670 v2 (Ivy Bridge/Sandy Bridge) 1 vCPUs Moderate 64-bit
    T1 Micro db.t1.micro 0.613 GiB 0 GiB (EBS only) Variable 1 vCPUs Very Low 64-bit
    T2 General Purpose Micro db.t2.micro 1 GiB 0 GiB (EBS only) Intel Xeon Family 1 vCPUs Low to Moderate 64-bit
    T2 General Purpose Small db.t2.small 2 GiB 0 GiB (EBS only) Intel Xeon Family 1 vCPUs Low to Moderate 64-bit
    M1 General Purpose Large db.m1.large 7.5 GiB 2×420 Intel Xeon Family 2 vCPUs Moderate 64-bit
    M2 High Memory Extra Large db.m2.xlarge 17.1 GiB 1×420 Intel Xeon Family 2 vCPUs Moderate 64-bit

    Часть параметров, которые конфигурируются: Allocated storage, Architecture settings, Auto minor version upgrade, Availability zone, AWS KMS key, Backup replication, Backup retention period, Backup target, Backup window, Character set, Collation, Copy tags to sna Database management type, Database port, DB engine version, DB instance class, DB instance identifier, DB parameter group, DB subnet group, Deletion protection, Encryption, Enhanced Monitoring, Engine type, Initial database name, License, Log exports, Mainten Master password, Master username, Microsoft SQL Server Windows Authentication, Multi-AZ deployment, National Character Set (NCHAR), Network type, Option group, Performance Insights, Provisioned IOPS, Public access, Storage autoscaling, Storage type, Time zone, Virtual Private Cloud (VPC),VPC Security Group (Firewall).

    Для некоторых параметров есть свои вложенные параметры.

    В противоположность варианты для создания Azure SQL

    Azure SQL имеет две общие модели развертывания, классифицируемые более компактно (их подробно опишу в следующих статьях об облачных базах).

    Первая модель

    Basic Standard Premium
    Target workload Разработка и производство Разработка и производство Разработка и производство
    Uptime SLA 99.99% 99.99% 99.99%
    Maximum backup retention 7 дней 35 дней 35 дней
    CPU Low Low, Medium, High Medium, High
    IO throughput (approximate) 1-5 IOPS per DTU 1-5 IOPS per DTU 25 IOPS per DTU
    IO latency (approximate) 5 ms (read), 10 ms (write) 5 ms (read), 10 ms (write) 2 ms (read/write)
    Columnstore indexing N/A S3 и выше Supported
    In-memory OLTP N/A N/A Supported
    Maximum DTU 5 3000 (S12) 4000 (P15)
    Maximum Storage Size 2 GB 250 GB 1 TB

    Вторая модель:

    General Purpose Business Critical
    Compute 1 to 16 vCore 1 to 80 vCore
    Storage Premium Remote storage, max 4 TB Premium Remote storage, max 4 TB
    IO throughput 500 IOPS на VCore 5000 IOPS для DTU VCore
    Backups RA-GRS, 7 – 35 дней RA-GRS, 7 – 35 дней

    То есть выбор сервиса унифицирован к типам нагрузки с постепенным масштабированием.

    Если Vcore – 1, 2, 4, 8, 16, 32 и так далее. Если DTU – 20, 50, 100, 200, 500, 1000 и так далее.

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

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

  • Настройка деплоя сервсиса в AWS

    Настройка деплоя сервсиса в AWS

    Среда для выполнения

    1. Зарегистрированный аккаунт AWS
    2. Развернутый кластер EKS 
    3. GitLab (проект приложения)

    Задача:

    Настроить CI/CD для подготовленного на GitLab проекта, который представляет собой RESTful микросервис Node.JS (framework nestJS). Микросервис в кластере ECS/EKS должен по умолчанию иметь 2 запущенные поды c равномерной балансировкой нагрузки.

    В задачу входит:

    1. Ознакомиться с проектом
    2. Настроить авто CI/CD из ветки develop для одного окружения 
    3. Объяснить что потребуется выполнить для настройки процесса для двух и более окружений (дев/стейдж/прод)
    4. Объяснить как сконфигурирован кластер EKS
    5. Объяснить как реализована балансировка нагрузки

    Решение:

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

    В начале для настройки деплоя в несколько окружений достаточно разделить их на уровне namespace кластера kubernetes. Доступ к этим окружениям можно разграничить на уровне RBAC.
    Настройки деплоя из одной ветки: в правилах прописать условие, которое будет содержвать информацию зз каких веток, тегов  делать деплой.
    В тестовом EKS кластере установлен агент GitLab, которой позволяет реализовать прозрачную интеграцию кластера kubernetes и GitLab. Так же этот агент используется для запуска GitLab раннеров, на которых выполняется пайплайн.

    • Для доступа к приложению из вне, в кластере установим nginx-ingress сервис.
    • Для доступа в репозиторий гитлаба добавим токен.
    • Балансировку нагрузки реализуем посредством LoadBalancer в AWS.

    Поддержку SSL возможно реализовать на двух разных уровнях, это может быть балансировщик AWS или же nginx-ingress. Для реализации на уровне nginx-ingress можно использовать сервис cert-manager, для автоматического выпуска и обновления сертификатов Let’s Encrypt.

    По окончанию получили результат.



    Результат состоит из 2-х шагов:

    • На первом этапе собирается контейнер из докер файла при помощи bind.  После чего загружается в репозиторий на GitLab.
    • На втором – меняем тег контейнера в кластере.

    Если приблизить это задание к продакшену, мы еще можем добавить шаг с обновлением контекста в Kubernetes, также стоит использовать докер файл с уже заранее собраный с помощью build приложением, чтобы использовать среду production вместо dev. Так же рекомендовано добавить простые проверки, тесты приложения. 

    Если Вам нужна помощь в реализации подобных задач, обращайтесь office@itfb.com.ua

  • Этапы нагрузочного тестирования

    Этапы нагрузочного тестирования

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

    Новости от клиента

    «3000. Нет, лучше 5000 пользователей! — Как-то услышали мы от клиента вместе с новостью, что он планирует привлекать в приложение активных пользователей.

    Что приходит? первое что приходит в голову, когда вы слышите об увеличении количества пользователей в приложении от 170 до 5000? Какие фичи заинтересуют этих пользователей или с каких платформ будет больше загрузок? Безусловно, это важные моменты. Но первые мысли, чтобы сервер не упал.

    Планирование

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

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

    План был таким:

    1. Выбрать фичи для нагрузочного тестирования и приоритезировать их.
    2. Определиться с инструментами для проведения нагрузочного тестирования.
    3. Составить план и провести расчеты.
    4. Создать отдельное окружение для тестирования.
    5. Провести ручное тестирование, чтобы проверить, все ли хорошо с frontend частью программы во время работы с большим количеством пользователей. И пофиксить баги.
    6. Составить тест-план и проверить нагрузку на небольшом количестве пользователей (10-20). Пофиксировать возникшие баги.
    7. Провести проверки для большего количества пользователей, постепенно увеличивая нагрузку на сервер и пофиксировать возникшие баги.
    8. Понять, какое максимальное количество активных пользователей может «выдержать» приложение.
    9. Предоставить отчет клиенту.

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

    Настройка перед началом

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

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

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

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

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

    Первые проверки при низкой нагрузке

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

    Тест-план состоял из 6 групп.

    • Login.
    • Follow/Unfollow сущности 1.
    • Create/Delete сущности 2.
    • Join/Left сущности 3.
    • CRUD с данными сущности 4.
    • Discussion (работа с чатами – самое коварное и самое интересное для тестирования).

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

    Увеличение нагрузки, количество ошибок и поиск их решения

    Мы начали увеличивать мощности и количество пользователей. Для начала проводили проверки по каждому треду отдельно. Тесты 10, 25, 50, 100, 200 пользователей – все работало довольно неплохо. Логин отрабатывал «как часы», но «проблемы» начались при погрузке других сущностей — часть проверок просто выдавали 500 ошибки на 300 пользователях.

    На скриншоте настройки тестирования. Предположим, что в тред-группе последовательно выполняются 5 запросов при работе 300 пользователей с задержкой в ​​1 секунду. Будут ли запросы работать как следует?

    Ответ – нет, сервер будет возвращать ошибки.

    Если увеличивается количество пользователей, нужно обращать внимание на Ramp-up period и давать возможность серверу успевать все в пределах допустимого времени. То есть плохим и малореалистичным будет сценарий, где мы даем для одного пользователя одну секунду на выполнение, допустим, 5 запросов, содержащих в себе разный набор данных (по количеству отправляемых параметров) в пределах одной тред-группы.

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

    После увеличения ramp-up period ошибок стало меньше, но они все еще возникали.

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

    В нашем случае для 300 пользователей был приемлем и реалистичен Ramp-up period в 30 секунд, то есть для дальнейших проверок минимальное соотношение количества пользователей к Ramp-up period было 10 к 1.

    Пора подключать несколько тредов к работе одновременно.

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

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

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

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

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

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

    • Предварительно подготовим медиа и текст, с которыми будем работать в будущем.
    • Для медиа нужно выбрать несколько поддерживаемых фото и видео различных форматов и размеров. Они могут храниться локально на ПК или в облачном хранилище проекта (второй вариант лучше, учитывая работу с тестами для всех членов команды). Затем необходимо указать путь к хранению этих файлов в HTTP Request и указать имя параметра, указывая его условный id (media_id):

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

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

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

    При работе с рандомом следует обратить внимание как на реализацию через язык скрипта, которым вы пишете, так и на стандартную функцию рандома в JMeter:
    ${__Random(p1, p2, p3)}, где P1 и р2 — нижний и верхний предел случайного числа соответственно, а р3 — имя переменного, где будет храниться случайно выбранное число.

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

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

    При возрастании нагрузки на сервер увеличивается объем оперативной памяти, CPU и т.п. Таким образом, по мере увеличения нагрузки появляется потребность в подключении дополнительных мощностей и происходит переход на следующий тарифный план (M10, M20, т. д.), а также подключаются дополнительные серверы -горизонтальное и вертикальное маштабирование.

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

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

    Результат проделанной работы

    Мы предоставили отчеты о проделанной работе клиенту и сошлись на том, что нагрузка в 9000 активных пользователей при запланированном росте до 20 000 зарегистрированных – очень хороший результат, которого мы смогли достичь в сжатые сроки. Для итоговых отчетов мы использовали генерируемые в течение последнего дня тестирования.

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

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

    Взяты с официального сайта Grafana.com

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

  • Зачем компаниям мигрировать в облачную инфраструктуру и как рассчитать риски

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

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

    Зачем компаниям переходить на облачную инфраструктуру

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

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

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

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

    1. Простота и быстрота доступа к корпоративным IT-сервисам. Например, почта, CRM, 1С, специализированный софт для профессиональной работы или SharePoint (это набор веб-приложений для организации совместной работы).
    2. Уменьшение затрат на ИТ-инфраструктуру. У крупных компаний часто многофилиальная структура. Типичным процессом работы с филиалом была настройка интернета, внутреннего телефона, покупка ноутбука, настройка всех систем, его отправка в другой город. В процесс вовлечены внутренние рабочие и внешние подрядчики. Поэтому удобнее и дешевле работать через облачный сервис, даже позволяющий использовать концепцию bring your own device. Разовая настройка и новый член команды может сразу работать.
    3. Уменьшение затрат путём планирования. $1 сегодня – это не $1 через месяц. Компаниям выгоднее вложить средства и получить прибыль, чем сразу вкладывать в CAPEX. Уже имея определенное количество оборудования компания может быть ограничена в запуске новых проектов. К примеру, в развертывании почтовой системы раздельно. Это влечет за собой много денег, покупку серверов, сервиса, дополнительных лицензий. В облаке, например, администратор всегда знает, сколько лицензионных программ у него задействовано сейчас. Это позволяет планировать и покупать именно то количество лицензий и ресурсов, которое необходимо, не тратя деньги на непривлеченные ресурсы.
    4. Централизация и сохранность. В облаке администрирования и управления практически находится в одном месте. Поэтому логично, что уровень безопасности выше. Ведь легче проследить за одной комнатой, чем охранять 16 разных комнат в разных городах. Также можно сэкономить на мониторинговых системах и специальном программном обеспечении для шифрования и защиты данных. Компания всегда знает, где ее данные, в каком они состоянии, куда они пошли и как вернулись. Это гораздо проще для внутренних служб безопасности, которые, например, проводят расследование при возможных утечках конфиденциальной информации.

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

    Как просчитать затраты на переход

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

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

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

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

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

    Бывает и такое, что выгоднее строить свое облако. Есть кейсы, в которых стоимость ежемесячной аренды облака достигала около $150 000. И из расчета капитальных затрат на 3 года компании было удобнее строить собственное облако.

    Сколько времени занимает переход в облако

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

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

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

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

    Какие риски существуют при миграции в облако

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

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

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

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

    Какие бывают вызовы для команды

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

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

    Что в результате

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

    Сам по себе переход не является чем-то трудным. Однако он требует квалифицированного подхода и анализа.

    Для миграции в облако обращайтесь office@itfb.com.ua

  • Мониторинг производительности приложений

    Мониторинг производительности приложений

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

    1. Мониторинг
    2. Профилирование
    3. Отслеживание исключений

    Давайте посмотрим на них по отдельности и на то, как они интегрируются друг с другом.

    Мониторинг

    Начнем с мониторинга. Раздел мониторинга в Tideways — это место, где вы можете получить общий обзор вашего приложения, в том числе:
    Какие части приложения оказывают наибольшее влияние на производительность, сгруппированные по

    1. слои, такие как базы данных SQL, HTTP, Redis, как показано в этой картинке или
    2. конечные точки автоматически обнаруживаются Tideways, зная о наиболее распространенных PHP-фреймворках, таких как Magento, Symfony, Shopware или Laravel.

    мониторинг производительности приложения

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

    отслеживание производительности приложения

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

    скорость загрузки приложения

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

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

    Профилирование

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

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

    Tideways поддерживает два типа профайлеров:

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

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

    профилирование приложения

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

    почему тормозит приложение

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

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

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

    Отслеживание исключений

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

    поиск причин ошибок в приложении

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

    Вывод

    Это краткий обзор Tideways, в котором основное внимание уделяется трем основным концепциям: профилированию , мониторингу и отслеживанию исключений . Используя эти три компонента в комбинации, вы можете быстро перейти от общего обзора к низкоуровневому детальному пониманию того, в чем заключаются проблемы в вашем приложении и как их исправить. Если вам нужна помощь с поиском узких мест оптимизацией, обращайтесь office@itfb.com.ua

  • Как воспользоваться бесплатным хостингом Amazon

    Как воспользоваться бесплатным хостингом Amazon

    EC2 (Elastic Cloud) – это облачный хостинг от Amazon, позволяющий быстро и удобно развертывать приложения. К примеру, Docker, Kubernetes, Python и bash-скрипты. В статье рассмотрим, как войти на экземпляр EC2 с помощью ssh-клиентов PuTTY, Termius и Termux.

    Для начала работы зарегистрируйтесь на сайте AWS и добавьте платежную карту. Рекомендую установить лимит на покупки в интернете, или иметь отдельную карту с 1$. Amazon однократно снимет и вернет его. После войдите в AWS в качестве пользователя root.

    В течение первых 12 месяцев Amazon предоставляет бесплатно 750 часов для экземпляра t2.micro и ОС (AMI) с меткой Free tier eligible. Эти часы могут быть использованы одним экземпляром, работающим в течение полнолуния (31 день * 24 часа = 744 часа), или несколькими экземплярами Amazon EC2, используемыми в течение месяца. Любые часы, превышающие бесплатный уровень, будут взиматься по ценам по требованию.

    Создание экземпляра

    После входа перейдите к сервису EC2 (Services >> Compute >> EC2), по желанию выберите локацию сервера (в верхнем уголке справа) и нажмите Launch instance.

    ec2

    Дайте название, выберите операционную систему (AMI) со значком free tier eligible и Instance type – t2.micro.

    Создание ключевой пары (Key pair)

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

    По умолчанию Amazon использует ключевую пару в качестве безопасной альтернативы паролю. Однако иногда необходимо использовать пароль. Рассмотрим оба способа входа.

    key pair

    Proceed without a key pair (not recommended) — продолжить с использованием пароля.

    Create new key pair – создать новую ключевую пару.

    После нажатия кнопки «Create key pair» на вашем компьютере сохранится файл с расширением .pem. Если для подключения к серверу вы будете использовать только PuTTy, можно сразу сгенерировать пару в формате .ppk.

    Нажмите кнопку Launch instance.

    Все виртуальные машины можно найти в боковом меню >> instances.

    Подключение через вебконсоль и установку пароля

    По умолчанию экземпляры ec2 не имеют аутентификации паролем. Однако его можно установить вручную через веб-интерфейс. Для подключения нажмите галочку в поле экземпляра и Connect.

    Затем введите команду sudo nano /etc/ssh/sshd_config

    Если переключиться на английскую раскладку, можно вставить команду с помощью Ctrl+V.

    Найдите строку «PasswordAuthentication» и измените значение «no» на «yes». Нажмите
    Ctrl+O сохранить изменения. Enter – подтвердить название файла. Ctrl+X – выйти.

    Придумайте и измените пароль пользователя с помощью команды
    sudo passwd ec2-user

    Перезапустите службу ssh
    sudo service sshd restart

    Вход с паролем через PuTTY

    PuTTY  – бесплатный и очень популярный ssh ​​клиент для Windows. Чтобы войти в экземпляр, введите ec2-user@54.234.225.175 , где цифры после собачки — публичный IP-адрес вашего экземпляра.

    Вход с ключевой парой через PuTTY

    Для начала превратите .pem файл в .ppk (ключ в формате PuTTY). Откройте программу PuTTygen и нажмите Load.

    В открывшемся окне справа выберите All Files (все файлы).

    Выберите файл .pem. Вы получите сообщение об успешном импорте, нажмите ОК. Щелкните Save private key (сохранить приватный ключ).

    Вы получите вопрос, нажмите «Да». Дайте любое название файла и сохраните в удобное вам место.

    Для подключения к серверу откройте PuTTy. В строке Hostname укажите Public IP адрес в формате ec2-user@54.234.225.175 или Public DNS в формате ec2-user@ec2-54-161-94-141.compute-1.amazonaws.com

    Чтобы загрузить ключ в боковом меню PuTTY, выберите SSH >> Auth и в строке Private file for authentication нажмите Browse. Выберите ранее сохраненный ключ .ppk.

    Для удобства рекомендую сохранить сессию. Это позволит не указывать пользовательские данные. Для этого в боковом меню выберите Session, в строке Saved Session укажите произвольное название и нажмите кнопку Save.

    Если вы получаете ошибки при входе, проверьте, выбран ли файл ключа (ssh >> auth), правильно ли указано имя пользователя, правильно ли указан публичный IP-адрес.

    Вход с паролем через Termius

    Termius  – удобный ssh-клиент для компьютеров (Windows, Mac, Linux) и мобильных (Android, IOS) с возможностью сохранения сессий, синхронизации сессий между клиентами, сохранения команд (снипеты). Чтобы войти на экземпляр EC2, укажите:

    • Hostname — IP-адрес экземпляра.
    • Username – имя пользователя.
    • Password – пароль экземпляра.

    По желанию укажите удобное для вас имя – Alias.

    Вход с ключевой парой через Termius

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

    • Hostname — IP-адрес экземпляра.
    • Username – имя пользователя.
    • Key – выберите частный ключ.

    По желанию укажите удобное для вас имя – Alias.

    Чтобы добавить приватный ключ, откройте файл .pem в любом текстовом редакторе и скопируйте его содержимое на телефон. В Termius нажмите поле Key, затем на + вверху справа, выберите Paste Key и вставьте частный ключ.

    Вход с паролем через Termux

    Termux  – мощный эмулятор терминала Android с открытым кодом. Минимальная базовая система устанавливается автоматически – дополнительные пакеты доступны с помощью менеджера пакетов APT.

    • termux-change-repo – клавишей Enter выберите репозитарий Main.
    • apt update — обновление пакета.
    • apt upgrade – обновить пакеты. Терминал задаст вам несколько вопросов по поводу версии программ, выбирайте версию по умолчанию (буква «n»).
    • pkg install openssh — установка пакета openssh.

    Войдите в свой экземпляр с помощью команды ssh ec2-user@18.212.236.59
    Примите ключ шифрования (fingerprint), введя «yes».

    Вход с ключевой парой через Termux

    Частные ключи Termux находятся в каталоге `~/.ssh` Чтобы добавить приватный ключ, откройте файл .pem в любом текстовом редакторе и скопируйте его содержимое на телефон.

    1. Перейдите в каталог ssh: cd ~/.ssh.
    2. Создайте файл id_rsa: nano id_rsa.
    3. Вставьте содержимое приватного ключа.
    4. Ctrl+O – сохраните изменения.
    5. Enter – подтвердите название файла.
    6. Ctrl+X – выйдите.

    Подключитесь к экземпляру с помощью команды: ssh -i id_rsa ec2-user@18.212.236.59 , где цифры после собачки — публичный IP-адрес вашего экземпляра.

    Как удалить экземпляр EC2

    Чтобы удалить экземпляр, нажмите на галочку рядом с ним и в верхнем углу выберите меню Instance state, выберите «Terminate Instance». Вы получите сообщение о приостановлении экземпляра.

  • Кто ты – Automation Engineer или SDET?

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

    Test Automation Engineer

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

    Здесь важен опыт именно UI автоматизации и способы решения типовых проблем, вроде правильно дождаться элемента или ввести текст так, чтобы не исчезали буквы. Конечно, нужно еще построить automation solution.

    Скорее всего, там будут page objects в каком-то виде и, возможно, на этом все. Очень простое решение с кучей подражания, которое на дистанции приводит к тому, что что-то сделать невозможно, или очень долго из-за ограничения дизайна решения, кроме того, что-то постоянно не работает и зеленые джобы – это праздник. Фиксиш в одном месте – падает в другом. У кого никогда не было такого опыта – поделитесь своей историей 🙂

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

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

    Мой первый проект по автоматизации начинался примерно так же, и даже люди, которых потом брали, не имели серьезного опыта с JS (на котором был написан проект). Тогда только появился ES6 и я помню вдохновенный разговор типа «я знаю разницу между map и forEach!». Это были интересные времена 🙂 Поделитесь своим первым опытом в автоматизации, очень интересно!

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

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

    Software Development Engineer in Test (SDET)

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

    По названию должности понятно, что навыки такого специалиста должны начинаться в первую очередь именно в программировании и направлены на автоматические тесты. Это означает, что специалист может сам определить, к какому уровню пирамиды тестирования относится тест и сам его имплементировал, оставляя UI уровню минимальное количество end-to-end flow.

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

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

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

    У меня было интервью, где front-end девелопер попросил меня написать сложный локатор. Я сказал, что даже не буду с этим возиться, а просто сделаю себе удобный тестовый id в нужном месте. Интервьюер ответил, что мои шансы на офер значительно выросли. На самом деле, именно это – довольно простой скил, значительно упрощающий написание тестов и это кратно быстрее и проще, чем просить девелоперов ставить локаторы.

    А теперь перейдем к более сложным вещам, а именно дизайн-архитектуре automation solution. Чем он проще (только page objects на подражании) тем, к сожалению, меньше возможностей и больше сложность в поддержке. А чтобы сделать гибкую систему, которую будет легко поддерживать и расширять, нужно иметь хорошие навыки в программировании. Ну, и поскольку SDET — это полноценный разработчик, он должен решать любые задачи, связанные с тестированием без ограничений.

    Необходимые навыки: знание и опыт мануального тестирования, знание и понимание языка программирования на уровне «девелоперы обращаются за помощью», знание и умение правильно применить паттерны программирования, умение писать код так, чтобы его понимали джуны, опыт автоматизации тестирования, понимание front-end/ back-end технологий на уровне «могу писать юнит тесты и фиксировать баги».

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

    Итоги

    1. Задача автоматизатора – написать как можно больше автотестов, тогда как задача SDET – написать как можно меньше тестов, но так, чтобы они принесли как можно больше пользы.
    2. Однажды на собеседовании кандидат на позицию senior сказал, что если бы он знал ответы на мои вопросы, то был бы разработчиком.
    3. Сейчас на украинском рынке для SDET работы меньше, потому что и стоит такой специалист больше и, опять-таки, многим нужно просто набрасывать тесты.
    4. И ответ на главный вопрос: вряд ли профессия автоматизатора когда-нибудь исчезнет, ​​но доля SDET будет постепенно расти. В Украине этот рост может быть несколько быстрее при векторе развития рынка в продукт.

    Сравнительная таблица

    Навыки Automation Engineer SDET
    Мануальное тестирование + +
    Программирование Базовый/средний уровень Продвинутый уровень
    Фреймворки для автотестов + Не обязательно
    Опыт UI автоматизации + +
    front-end/back-end технологии – +