Це добре працює, коли команда( і кастомер, котрий теж може взаємодіяти з платформою) в одній таймзоні, в інших же випадках вже краще якісь ephemeral environments, котрі, умовно, з Terraform/ CloudFormation розгортають середовище під тестування конкретної фічі та видаляють після роботи з ним
Направду трохи нестандартний підхід для захисту інфраструктури.
Навіщо видавати ключі, якщо можна використовувати ролі та налаштовувати пермішни? GitLab прекрасно інтегрується через OIDC з AWS, що дозволяє уникнути використання ключів. Це супер сек’юрно та надійно, оскільки видається тимчасовий токен для доступу до ресурсів, обмежених роллю.
Для моніторингу доступу до ресурсів певного типу можна створити окрему роль та призначити її відповідній групі користувачів. AWS Config Rules допоможе моніторити та реагувати на використання ресурсів, що не відповідають політикам компанії. Доступ до сервісів можна обмежити через створення окремих SCP (Service Control Policies).
Можливо, я щось неправильно вказав, перепрошую, не до кінця зрозуміла специфіка проекту.
Запросите у product owner-а данные о проценте допустимой погрешности системы — вы сэкономите себе уйму времени и нервов.
Зачем? Вы на этапе тестирования проверяете «допустимую погрешность», не понимая, как она получена( не зная алгоритма обучения и способа вычисления этой самой «допустимой погрешности»)?
Запросите у заказчика как можно большее количество тестовых данных (в нашем случае — это были анкеты людей). Чем больше валидных входных данных у вас будет, тем проще будет составить адекватный data setup и начать обучать систему.
Какое отношение обучение «системы» имеет к планированию тестирования?
согласен, но если у человека нет понимания работы современных веб-продуктов, допустим понимания интеграции данных из внешних источников, или нет опыта работы по Agile, это влияет на скорость коммуникации в команде разработки, где BA без опыта и современного тех бекграунда будет как информационное bottle neck
вроде ж про веб интерфейсы нигде не указано, но если человек работает с сугубо банковским внутренним софтом, то он может не сталкиваться с современными вещами из веб-разработки.
как раз интересует естественный, но интенсивный путь, вряд ли можно не честным способом обрести новые знания) а в кавычки взято по причине указания аналогии дообучения к процессам обновления софта/железа в технике
Спасибо большое за исчерпывающий крутой комментарий. Интересная точка зрения
Вебинар можно приобрести в записи?
Здравствуйте. Мне кажется, будет полезно посмотреть материал про «’эмоциональный интеллект». Именно этот тип интеллекта позволяет в процессе коммуникации правильно выражать свои эмоции и расшифровывать эмоции собеседника в случае вербального взаимодействия. На предмет невербалики — ничего не могу подсказать. Сугубо моё субъективное мнение.
Спасибо!
Спасибо!
Премного благодарен!
Дякую за чудову статтю з наглядними прикладами. Цікаво, яким чином вдалось скоротити кости по ElastiCache? Обрали більш сучасний тип інстансу та додали autoscaling? Чи розглядали в якості альтернативи ElastiCache окремий сервіс Redis Enterprise ? Наперед дякую за відповіді