Важное напоминание для системных аналитиков, которые хотят расти в Senior и работать со сложными проектами, которыми пользуются миллионы пользователей:
Уже совсем скоро стартует практическая программа:
🌟 Проектирование архитектуры
🗓 Старт 29 февраля 2024
🔗 Подробности о программе и заявка на предзапись
🎁 С 16 до 25 февраля открыта предзапись на специальных условиях.
Программа подойдёт только для опытных системных аналитиков (middle и выше).
Уже совсем скоро стартует практическая программа:
🌟 Проектирование архитектуры
🗓 Старт 29 февраля 2024
🔗 Подробности о программе и заявка на предзапись
🎁 С 16 до 25 февраля открыта предзапись на специальных условиях.
Программа подойдёт только для опытных системных аналитиков (middle и выше).
❤1
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
💫 ПОРТФОЛИО СИСТЕМНОГО АНАЛИТИКА 💫
В новом выпуске подкаста мы углубляемся в тему создания портфолио для системных аналитиков. В эпизоде подробно разбирается, почему портфолио является неотъемлемой частью карьерного роста аналитика, как начать его формировать, особенно если вы только начинаете карьеру системного аналитика, и какие инструменты могут помочь в этом.
Екатерина Ананьева делится советами по демонстрации портфолио работодателям и объясняет, в каких случаях оно может стать ключевым фактором при устройстве на работу. Подкаст включает примеры артефактов, которые можно включить в портфолио, и подчеркивает важность подхода к его созданию для презентации себя как специалиста.
Обсуждение вдохновлено вопросом из Telegram-чата сообщества GetAnalyst и будет полезно как для начинающих, так и для опытных системных аналитиков, стремящихся продемонстрировать свой профессионализм и навыки потенциальным работодателям.
00:20 - Введение и предыстория выбора темы
2:32 - Определение портфолио
5:22 - Примеры портфолио для разных специалистов и его назначение
10:45 - Что входит в портфолио системного аналитика
15:47 - Когда и для чего системному аналитику нужно портфолио, соблюдение корпоративной тайны
23:33 - Опыт использования портфолио и как оно помогло устроиться на позицию стажера системного аналитика
25:57 - Что можно использовать для портфолио системного аналитика - итоги
31:01 - С помощью каких инструментов и ресурсов формировать портфолио
35:20 - Обязательно ли наличие портфолио для системного аналитика
37:11 - Рекомендации слушателям
Эпизод доступен в:
⏯ Apple Podcast
⏯ YouTube
⏯ Telegram
⏯ Spotify
⏯ Amazon Music
*Яндекс.Музыка в процессе. Ссылку добавим.
Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!
В новом выпуске подкаста мы углубляемся в тему создания портфолио для системных аналитиков. В эпизоде подробно разбирается, почему портфолио является неотъемлемой частью карьерного роста аналитика, как начать его формировать, особенно если вы только начинаете карьеру системного аналитика, и какие инструменты могут помочь в этом.
Екатерина Ананьева делится советами по демонстрации портфолио работодателям и объясняет, в каких случаях оно может стать ключевым фактором при устройстве на работу. Подкаст включает примеры артефактов, которые можно включить в портфолио, и подчеркивает важность подхода к его созданию для презентации себя как специалиста.
Обсуждение вдохновлено вопросом из Telegram-чата сообщества GetAnalyst и будет полезно как для начинающих, так и для опытных системных аналитиков, стремящихся продемонстрировать свой профессионализм и навыки потенциальным работодателям.
00:20 - Введение и предыстория выбора темы
2:32 - Определение портфолио
5:22 - Примеры портфолио для разных специалистов и его назначение
10:45 - Что входит в портфолио системного аналитика
15:47 - Когда и для чего системному аналитику нужно портфолио, соблюдение корпоративной тайны
23:33 - Опыт использования портфолио и как оно помогло устроиться на позицию стажера системного аналитика
25:57 - Что можно использовать для портфолио системного аналитика - итоги
31:01 - С помощью каких инструментов и ресурсов формировать портфолио
35:20 - Обязательно ли наличие портфолио для системного аналитика
37:11 - Рекомендации слушателям
Эпизод доступен в:
⏯ Apple Podcast
⏯ YouTube
⏯ Telegram
⏯ Spotify
⏯ Amazon Music
*Яндекс.Музыка в процессе. Ссылку добавим.
Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!
❤11👍4🥰1🤩1
🗓 Вебинар по архитектуре 29 февраля 🗓
Работа с задачами на Backend может стать настоящим испытанием для системного аналитика: интеграции, API, архитектура. Без глубокого понимания этих тем работа может казаться игрой в "Повезёт - Не Повезёт".
Получаете вопросы от разработчиков Backend из набора непонятных терминов, которые заставляют вас обращаться к Google?
На командных встречах сложно уловить суть происходящего, а перспектива работы на новом проекте с системным архитектором кажется пугающей? Давайте это менять.
Практический вебинар, чтобы разобраться с темой:
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
План
1. Роль системного аналитика в проектировании архитектуры
2. Знакомство с проектом
3. Проектирование монолита
4. Переход к сервисам (SOA) и микросервисам (MSA)
5. Проблемы разделения монолита на микросервисы
6. Что нужно знать системному аналитику про работу с архитектурой
Эти навыки по проектированию архитектуры помогут перейти на новый уровень в системном анализе, и стать более ценным специалистом для вашей компании.
Готовы освоить новый навык?
До встречи в прямом эфире!
Работа с задачами на Backend может стать настоящим испытанием для системного аналитика: интеграции, API, архитектура. Без глубокого понимания этих тем работа может казаться игрой в "Повезёт - Не Повезёт".
Получаете вопросы от разработчиков Backend из набора непонятных терминов, которые заставляют вас обращаться к Google?
На командных встречах сложно уловить суть происходящего, а перспектива работы на новом проекте с системным архитектором кажется пугающей? Давайте это менять.
Практический вебинар, чтобы разобраться с темой:
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
План
1. Роль системного аналитика в проектировании архитектуры
2. Знакомство с проектом
3. Проектирование монолита
4. Переход к сервисам (SOA) и микросервисам (MSA)
5. Проблемы разделения монолита на микросервисы
6. Что нужно знать системному аналитику про работу с архитектурой
Эти навыки по проектированию архитектуры помогут перейти на новый уровень в системном анализе, и стать более ценным специалистом для вашей компании.
Готовы освоить новый навык?
До встречи в прямом эфире!
👍23❤8🥰2
Привет! Начнем неделю с обзора исходной схемы архитектуры по проекту GtTickets - монолит.
Что мы видим на схеме архитектуры:
🔸 Сервер (Backend)
Единое приложение, которое обеспечивает всех хранение данных в БД и реализацию всех функциональных возможностей приложения.
При разработке использовали принцип модульной архитектуры, поэтому уже сейчас можно детализировать схему Backend и показать модули: поиск рейсов, бронирования, платежи, пользователи, отчеты, уведомления.
🔸🔸 Одна база данных, без делений на схемы. Внутри более 100 таблиц.
🔸🔸 REST API для обеспечения работы пользовательских приложений. Все, что отображается на экранах пользовательских приложений, получается ими через разработанный внутренний REST API. который при желании можно сделать публичным (открытым, с публичной API-документацией)
🔸 МП пользователя Android
Приложение пользователя для обеспечения функциональности поиска и бронирования билетов.
Приложение запрашивает и получает данные только от сервера Backend GetTickets. Среди внешних интеграций можно выделить только интеграцию с системой уведомлений Firebase Cloud Messaging.
🔸 МП пользователя iOS
Аналогично Android. Но интеграция.с Firebase иным способом.
🔸 Веб-приложение пользователя
Аналогично Android, но внешние интеграции для уведомлений не предусмотрены.
🔸 Веб-приложение администратора
Это самый неприятный вариант монолитного фронтенда, когда код бэкенда и фронтенда в одном месте, и данные для приложения администратора получаются не через API, а напрямую из БД с помощью SQL-запросов (frontend - веб-приложение, пользовательское приложение, пользовательский интерфейс работы с системой).
Почему могло быть принято решение разработать монолитный фронтенд без API, как для пользовательских приложений? Не было необходимости повторять функциональность для трех разных клиентов, как это есть для пользовательских приложений iOS, Android, Web. А также это внутреннее приложение, для сотрудников. Решили упростить реализацию.
Продолжение 👇
#АрхитектураGA #GetTickets
Что мы видим на схеме архитектуры:
🔸 Сервер (Backend)
Единое приложение, которое обеспечивает всех хранение данных в БД и реализацию всех функциональных возможностей приложения.
При разработке использовали принцип модульной архитектуры, поэтому уже сейчас можно детализировать схему Backend и показать модули: поиск рейсов, бронирования, платежи, пользователи, отчеты, уведомления.
🔸🔸 Одна база данных, без делений на схемы. Внутри более 100 таблиц.
🔸🔸 REST API для обеспечения работы пользовательских приложений. Все, что отображается на экранах пользовательских приложений, получается ими через разработанный внутренний REST API. который при желании можно сделать публичным (открытым, с публичной API-документацией)
🔸 МП пользователя Android
Приложение пользователя для обеспечения функциональности поиска и бронирования билетов.
Приложение запрашивает и получает данные только от сервера Backend GetTickets. Среди внешних интеграций можно выделить только интеграцию с системой уведомлений Firebase Cloud Messaging.
🔸 МП пользователя iOS
Аналогично Android. Но интеграция.с Firebase иным способом.
🔸 Веб-приложение пользователя
Аналогично Android, но внешние интеграции для уведомлений не предусмотрены.
🔸 Веб-приложение администратора
Это самый неприятный вариант монолитного фронтенда, когда код бэкенда и фронтенда в одном месте, и данные для приложения администратора получаются не через API, а напрямую из БД с помощью SQL-запросов (frontend - веб-приложение, пользовательское приложение, пользовательский интерфейс работы с системой).
Почему могло быть принято решение разработать монолитный фронтенд без API, как для пользовательских приложений? Не было необходимости повторять функциональность для трех разных клиентов, как это есть для пользовательских приложений iOS, Android, Web. А также это внутреннее приложение, для сотрудников. Решили упростить реализацию.
Продолжение 👇
#АрхитектураGA #GetTickets
👍11❤5🔥2
🧩 Внешние системы - интеграции с GetTickets:
🔸 Группа систем для поиска рейсов и бронирования авиабилетов
С каждой из внешних систем интеграция по API (это могут быть REST, SOAP, GraphQL и другие). Из схемы видно, что для интеграций используется API внешних систем.
На основании схемы архитектуры я могу описать, что для поиска рейсов в приложении Android будет выполняться последовательность шагов:
1. Отправить запрос на поиск в REST API GetTickets, используя интеграционный метод.
2. REST API GetTickets принимает запрос и выполняет его обработку.
В процессе обработки запроса выполняется вызов внешних систем поиска рейсов и бронирований по API (АвиаСэйлс, СкайСканер, Аэрофлот и другие).
3. Полученный ответ от внешней системы по API обрабатывается в соответствии с маппингом данных (таблицей сопоставления).
Все необходимые данные могут быть записаны в единую БД системы (если запрос реализуется асинхронно - в два вызова отдельных метода, с созданием отложенной задачи POST и получением ответа GET, то это актуально).
4. Итоговый результат возвращается в ответе от REST API GetTickets на приложение Android.
🔸 Платежная система ЮКасса
Используется для получения оплаты от пользователей за бронирования. Интеграция реализована в модуле приема и обработки платежей. После каждой транзакции в единую БД системы записываются данные по платежам (id, параметры чеков и другие).
🔸 Система отправки СМС
Используется для отправки подтверждения аккаунта пользователя (модуль управления пользователями) и информации о бронировании после успешной оплаты (модуль бронирований).
🔸 Система отправки push-уведомлений
Используется для информирования пользователей об изменениях цен и событиях по оплаченным бронированиям.
#АрхитектураGA #GetTickets
🔸 Группа систем для поиска рейсов и бронирования авиабилетов
С каждой из внешних систем интеграция по API (это могут быть REST, SOAP, GraphQL и другие). Из схемы видно, что для интеграций используется API внешних систем.
На основании схемы архитектуры я могу описать, что для поиска рейсов в приложении Android будет выполняться последовательность шагов:
1. Отправить запрос на поиск в REST API GetTickets, используя интеграционный метод.
2. REST API GetTickets принимает запрос и выполняет его обработку.
В процессе обработки запроса выполняется вызов внешних систем поиска рейсов и бронирований по API (АвиаСэйлс, СкайСканер, Аэрофлот и другие).
3. Полученный ответ от внешней системы по API обрабатывается в соответствии с маппингом данных (таблицей сопоставления).
Все необходимые данные могут быть записаны в единую БД системы (если запрос реализуется асинхронно - в два вызова отдельных метода, с созданием отложенной задачи POST и получением ответа GET, то это актуально).
4. Итоговый результат возвращается в ответе от REST API GetTickets на приложение Android.
🔸 Платежная система ЮКасса
Используется для получения оплаты от пользователей за бронирования. Интеграция реализована в модуле приема и обработки платежей. После каждой транзакции в единую БД системы записываются данные по платежам (id, параметры чеков и другие).
🔸 Система отправки СМС
Используется для отправки подтверждения аккаунта пользователя (модуль управления пользователями) и информации о бронировании после успешной оплаты (модуль бронирований).
🔸 Система отправки push-уведомлений
Используется для информирования пользователей об изменениях цен и событиях по оплаченным бронированиям.
#АрхитектураGA #GetTickets
👍4
В GetAnalyst мне удалось поработать со специалистами в системном и бизнес-анализе разного уровня. У многих на старте работы со мной жалобы на хаотичностью в знаниях. При этом неважно с какой темой специалист хочет разобраться.
Думаю это происходит по 2-м причинам ⤵️
▪️ Навыки есть, но используются бессистемно.
Если выражаться метафорой, то это напоминает огромный пазл, который собрали по частям, но их ещё не скрепили вместе, чтобы увидеть картинку целиком.
▪️ Желание получить быстрые результаты
Специалист стремится к мгновенным результатам и порой не уделяет должного внимания структуре - не погружаются углублённо в предмет.
Кусочки знаний не помогут. В любой области надо: увидеть картину целиком, познать нюансы и копать в глубину. Именно глубокое понимание предмета и позволяет расти на долгосрочной основе ☝️
❌️ Сила не в том, чтобы хватать знания хаотично время от времени.
✅️ Сила в умении поддерживать крутой результат снова и снова, используя полученные структурно знания.
Моя цель в GetAnalyst обеспечить вас самой важной экспертной информацией и практикой в системном анализе. При этом “самое важное” не значит бегло пройтись по верхам. Это значит последовательно и глубоко осваивать ровно те знания и навыки, которые ежедневно приносят результаты в работе, используются постоянно.
Я хочу превратить сложное в понятное, объяснить всё при помощи простых бытовых и наглядных примеров, чтобы вы могли сделать ассоциации в своей памяти, и знать как ходить "влево" и "право" за пределы базовой теории.
Для меня важно построить для вас структурированную теоретическую базу связанную с применением в реальной практике. Чтобы из проекта в проект вы самостоятельно видели и разбирались как работают системы “от” и “до”: видели «глубину», а не только верхушку айсберга.
Что ещё могу гарантировать - команда GetAnalyst всегда поддержит и направит, подскажет пути роста и даст инструменты для этого.
И помните: вы уже крутые и опытные специалисты, а мы лишь помогаем усиливать ваши навыки 🤝❤️
Думаю это происходит по 2-м причинам ⤵️
▪️ Навыки есть, но используются бессистемно.
Если выражаться метафорой, то это напоминает огромный пазл, который собрали по частям, но их ещё не скрепили вместе, чтобы увидеть картинку целиком.
▪️ Желание получить быстрые результаты
Специалист стремится к мгновенным результатам и порой не уделяет должного внимания структуре - не погружаются углублённо в предмет.
Кусочки знаний не помогут. В любой области надо: увидеть картину целиком, познать нюансы и копать в глубину. Именно глубокое понимание предмета и позволяет расти на долгосрочной основе ☝️
❌️ Сила не в том, чтобы хватать знания хаотично время от времени.
✅️ Сила в умении поддерживать крутой результат снова и снова, используя полученные структурно знания.
Моя цель в GetAnalyst обеспечить вас самой важной экспертной информацией и практикой в системном анализе. При этом “самое важное” не значит бегло пройтись по верхам. Это значит последовательно и глубоко осваивать ровно те знания и навыки, которые ежедневно приносят результаты в работе, используются постоянно.
Я хочу превратить сложное в понятное, объяснить всё при помощи простых бытовых и наглядных примеров, чтобы вы могли сделать ассоциации в своей памяти, и знать как ходить "влево" и "право" за пределы базовой теории.
Для меня важно построить для вас структурированную теоретическую базу связанную с применением в реальной практике. Чтобы из проекта в проект вы самостоятельно видели и разбирались как работают системы “от” и “до”: видели «глубину», а не только верхушку айсберга.
Что ещё могу гарантировать - команда GetAnalyst всегда поддержит и направит, подскажет пути роста и даст инструменты для этого.
И помните: вы уже крутые и опытные специалисты, а мы лишь помогаем усиливать ваши навыки 🤝❤️
❤30👍7
⭐ Масштабирование - что важно понимать системному аналитику ⭐
Термин "масштабироваться" в контексте IT относится к способности системы, приложения или сервиса адаптироваться к изменяющемуся объёму работы или запросов, увеличивая или уменьшая ресурсы и мощности для обеспечения эффективной работы.
Масштабирование может быть вертикальным или горизонтальным.
⭐ Вертикальное масштабирование (scaling up/down) означает добавление ресурсов к одному серверу или экземпляру приложения, например, увеличение объёма оперативной памяти, мощности процессора или места на диске.
Это сравнимо с переездом из маленькой квартиры в большую: вы получаете больше места и ресурсов для своих нужд. Вертикальное масштабирование имеет свои ограничения, связанные с максимально доступными ресурсами оборудования.
⭐ Горизонтальное масштабирование (scaling out/in) подразумевает добавление дополнительных экземпляров серверов или приложений, работающих параллельно, для распределения нагрузки. Т.е. запускаются одинаковые копии приложений.
Это можно сравнить с созданием сети из множества магазинов, каждый из которых обслуживает своих клиентов: если один магазин переполнен, клиенты могут перейти в другой.
Горизонтальное масштабирование обычно предпочтительнее, так как оно обеспечивает более высокую доступность и устойчивость к отказам.
➡️ Эти определения важно знать при работе с архитектурой систем, чтобы точно понимать, почему выбирают микросервисы вместо монолита.
Пример:
Тормозит функция поиска рейсов в системе GetTickets. Что лучше предпринять, чтобы поддержать стабильную работу?
А. Добавить еще оперативной памяти на всё запущенное приложение-монолит. (платим за память)
Б. Купить еще один такой же сервер и запустить приложение на нём. (платим за еще одну копию огромного сервера)
В. Выделить сервис поиска рейсов в отдельный микросервис, установить на отдельный сервер, и докупить несколько дополнительных копий таких же маленьких серверов, чтобы увеличить пропускную способность.
Угадаете ответ? 🙂
#АрхитектураGA #GetTickets
Термин "масштабироваться" в контексте IT относится к способности системы, приложения или сервиса адаптироваться к изменяющемуся объёму работы или запросов, увеличивая или уменьшая ресурсы и мощности для обеспечения эффективной работы.
Масштабирование может быть вертикальным или горизонтальным.
⭐ Вертикальное масштабирование (scaling up/down) означает добавление ресурсов к одному серверу или экземпляру приложения, например, увеличение объёма оперативной памяти, мощности процессора или места на диске.
Это сравнимо с переездом из маленькой квартиры в большую: вы получаете больше места и ресурсов для своих нужд. Вертикальное масштабирование имеет свои ограничения, связанные с максимально доступными ресурсами оборудования.
⭐ Горизонтальное масштабирование (scaling out/in) подразумевает добавление дополнительных экземпляров серверов или приложений, работающих параллельно, для распределения нагрузки. Т.е. запускаются одинаковые копии приложений.
Это можно сравнить с созданием сети из множества магазинов, каждый из которых обслуживает своих клиентов: если один магазин переполнен, клиенты могут перейти в другой.
Горизонтальное масштабирование обычно предпочтительнее, так как оно обеспечивает более высокую доступность и устойчивость к отказам.
➡️ Эти определения важно знать при работе с архитектурой систем, чтобы точно понимать, почему выбирают микросервисы вместо монолита.
Пример:
Тормозит функция поиска рейсов в системе GetTickets. Что лучше предпринять, чтобы поддержать стабильную работу?
А. Добавить еще оперативной памяти на всё запущенное приложение-монолит. (платим за память)
Б. Купить еще один такой же сервер и запустить приложение на нём. (платим за еще одну копию огромного сервера)
В. Выделить сервис поиска рейсов в отдельный микросервис, установить на отдельный сервер, и докупить несколько дополнительных копий таких же маленьких серверов, чтобы увеличить пропускную способность.
Угадаете ответ? 🙂
#АрхитектураGA #GetTickets
👍16❤1
🗓 Вебинар по архитектуре 29 февраля 🗓
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
За один вечер:
🌟 Поймете основы проектирования архитектуры.
🌟 Разберетесь в отличиях монолита, сервисов и микросервисов.
🌟 Научитесь проектировать архитектуру с нуля.
🌟 Узнаете, как происходит переезд с монолита на микросервисы.
🌟 Получите готовые схемы и подходы по проектированию.
До встречи в четверг!
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
За один вечер:
🌟 Поймете основы проектирования архитектуры.
🌟 Разберетесь в отличиях монолита, сервисов и микросервисов.
🌟 Научитесь проектировать архитектуру с нуля.
🌟 Узнаете, как происходит переезд с монолита на микросервисы.
🌟 Получите готовые схемы и подходы по проектированию.
До встречи в четверг!
❤18
🔐❌ Пренебрежение безопасностью при проектировании архитектуры ❌🔐
Если в процессе разработки системы не уделяется должное внимание мерам защиты от внешних угроз, то это может привести к потере конфиденциальных данных, финансовым потерям и ущербу для репутации бизнеса.
Примеры угроз безопасности:
🔎 Кража данных
- Медицинские информационные системы с данными о пациентах.
- Онлайн-магазины с клиентскими базами.
🔎 Атаки типа "отказ в обслуживании" (DoS-атака) направлены на выведение из строя системы или ее компонентов, что делает ресурсы недоступными для реальных пользователей. Это может быть достигнуто путем перегрузки серверов большим количеством запросов или эксплуатацией программных уязвимостей.
Почему так происходит:
➖ Ограниченные ресурсы: проекты с ограниченным бюджетом и сжатыми сроками.
➖ Недостаток знаний: отсутствие в команде специалистов по безопасности или недостаточное понимание актуальных угроз и методов защиты.
➖ Недооценка рисков:
недостаточное понимание последствий.
➖ Незнание технологий.
Рекомендации:
✅ Разрабатывайте систему таким образом, чтобы каждый компонент, модуль или пользователь имел только те привилегии, которые необходимы для выполнения своих задач. Это уменьшает потенциальный ущерб от уязвимостей.
✅ Проектируйте систему с четким разделением ответственности между компонентами. Это позволяет изолировать и защитить важные части системы.
✅ Используйте современные методы шифрования для защиты данных в хранилищах и при передаче.
✅ Отслеживайте подозрительную активность через средства аудита.
✅ Внедряйте средства безопасности.
✅ Проводите тестирование системы на проникновение с помощью внешних экспертов или инструментов.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ на вопрос в статье:
🔗 Ошибки в проектировании архитектуры: на что обращать внимание
#АрхитектураGA
Если в процессе разработки системы не уделяется должное внимание мерам защиты от внешних угроз, то это может привести к потере конфиденциальных данных, финансовым потерям и ущербу для репутации бизнеса.
Примеры угроз безопасности:
🔎 Кража данных
- Медицинские информационные системы с данными о пациентах.
- Онлайн-магазины с клиентскими базами.
🔎 Атаки типа "отказ в обслуживании" (DoS-атака) направлены на выведение из строя системы или ее компонентов, что делает ресурсы недоступными для реальных пользователей. Это может быть достигнуто путем перегрузки серверов большим количеством запросов или эксплуатацией программных уязвимостей.
Почему так происходит:
➖ Ограниченные ресурсы: проекты с ограниченным бюджетом и сжатыми сроками.
➖ Недостаток знаний: отсутствие в команде специалистов по безопасности или недостаточное понимание актуальных угроз и методов защиты.
➖ Недооценка рисков:
недостаточное понимание последствий.
➖ Незнание технологий.
Рекомендации:
✅ Разрабатывайте систему таким образом, чтобы каждый компонент, модуль или пользователь имел только те привилегии, которые необходимы для выполнения своих задач. Это уменьшает потенциальный ущерб от уязвимостей.
✅ Проектируйте систему с четким разделением ответственности между компонентами. Это позволяет изолировать и защитить важные части системы.
✅ Используйте современные методы шифрования для защиты данных в хранилищах и при передаче.
✅ Отслеживайте подозрительную активность через средства аудита.
✅ Внедряйте средства безопасности.
✅ Проводите тестирование системы на проникновение с помощью внешних экспертов или инструментов.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ на вопрос в статье:
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍4❤🔥2🔥1
Встречаемся сегодня ОНЛАЙН на практическом вебинаре по архитектуре 😉
🟢 Проектирование архитектуры: от монолита к микросервисам
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
План
1. Роль системного аналитика в проектировании архитектуры
2. Знакомство с проектом
3. Проектирование монолита
4. Переход к сервисам (SOA) и микросервисам (MSA)
5. Проблемы разделения монолита на микросервисы
6. Что нужно знать системному аналитику про работу с архитектурой
Подключаться лучше с компьютера: будем работать со схемами и вместе описывать требования к переезду с монолита на микросервисы для проекта.
Увидимся в 19:00 Мск! 🙂
План
1. Роль системного аналитика в проектировании архитектуры
2. Знакомство с проектом
3. Проектирование монолита
4. Переход к сервисам (SOA) и микросервисам (MSA)
5. Проблемы разделения монолита на микросервисы
6. Что нужно знать системному аналитику про работу с архитектурой
Подключаться лучше с компьютера: будем работать со схемами и вместе описывать требования к переезду с монолита на микросервисы для проекта.
Увидимся в 19:00 Мск! 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👎1
❗️До начала 15 минут❗️
📹 Проектирование архитектуры: от монолита к микросервисам
Переходите по ссылке: https://pruffme.com/webinar/?id=00c7ce6f9597534c6124203cae11abb5 и начинаем!
Please open Telegram to view this post
VIEW IN TELEGRAM
Pruffme
Проектирование архитектуры: от монолита к микросервисам
❤14
Читаю обратную связь и радуюсь! ❤️ Спасибо вам огромное за активное участие в практике по проектированию перехода от монолита к микросервисной архитектуре!
Что у нас получилось:
✅ Разобрали вакансию системного архитектора и выделили его ключевые навыки и обязанности. Сравнили с вакансиями системных аналитиков и выделили общие задачи.
✅ Спроектировали монолитную архитектуру GetTickets, переделав опубликованную в канале схему с обычным монолитом на схему с модульным монолитом. Коллеги выделили модули и мы вместе определили задачи под них. Посмотрели интересный кейс с интеграциями.
✅ Разобрали принципы проектирования сервисной (SOA) и микросервисной (MSA) архитектуры. Четко определили отличия между ними и на практике с GetTickets выбирали, что будет сервисами, а что микросервисами в новой целевой схеме архитектуры.
✅ Проработали сценарий переезда на примере одного из модулей: как вынести модуль из монолита и превратить модуль в микросервис. И почему модульный монолит в этом плане прекрасен.
✅ Обсудили важное: поговорили о недостатках микросервисов и преимуществах монолита. Именно так. И разобрали это на примерах из опыта.
Дала много ценной информации, которую сразу применяли на практике. По итогам получили 3 схемы архитектуры и практический кейс в копилку! 🙌
❗️Повтор проведём. Информация о нём будет опубликована завтра 🙂
А продолжение практики будет уже во вторник, в рамках программы
📚 Проектирование архитектуры,
где мы будем знакомиться с проектом, с шаблонами проектирования архитектуры и проектировать архитектуру в прямом эфире!
Жду встречу с новой командой! 🤩
Что у нас получилось:
✅ Разобрали вакансию системного архитектора и выделили его ключевые навыки и обязанности. Сравнили с вакансиями системных аналитиков и выделили общие задачи.
✅ Спроектировали монолитную архитектуру GetTickets, переделав опубликованную в канале схему с обычным монолитом на схему с модульным монолитом. Коллеги выделили модули и мы вместе определили задачи под них. Посмотрели интересный кейс с интеграциями.
✅ Разобрали принципы проектирования сервисной (SOA) и микросервисной (MSA) архитектуры. Четко определили отличия между ними и на практике с GetTickets выбирали, что будет сервисами, а что микросервисами в новой целевой схеме архитектуры.
✅ Проработали сценарий переезда на примере одного из модулей: как вынести модуль из монолита и превратить модуль в микросервис. И почему модульный монолит в этом плане прекрасен.
✅ Обсудили важное: поговорили о недостатках микросервисов и преимуществах монолита. Именно так. И разобрали это на примерах из опыта.
Дала много ценной информации, которую сразу применяли на практике. По итогам получили 3 схемы архитектуры и практический кейс в копилку! 🙌
❗️Повтор проведём. Информация о нём будет опубликована завтра 🙂
А продолжение практики будет уже во вторник, в рамках программы
📚 Проектирование архитектуры,
где мы будем знакомиться с проектом, с шаблонами проектирования архитектуры и проектировать архитектуру в прямом эфире!
Жду встречу с новой командой! 🤩
❤25
Архитектура ПО — это Вселенная. Все очень сложно, но если все правильно, то все невероятно просто. Шаг за шагом познаю что и как. Ищу лучшие практики и шаблоны. В конечном счете, в очередной раз делаю одно и то же заключение:
Изученные правильные практики и шаблоны проектирования лишь вектор, который вдохновляет на красивые и уникальные решения.
В этой статье нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто зафиксировала мысли, которые надо не забывать при решении очередной задачи 🙂
Изученные правильные практики и шаблоны проектирования лишь вектор, который вдохновляет на красивые и уникальные решения.
В этой статье нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто зафиксировала мысли, которые надо не забывать при решении очередной задачи 🙂
❤12👏8😍4
🙌 Запись "Проектирование архитектуры: от монолита к микросервисам" 🙌
Мы благодарим всех, кто смог подключиться онлайн в этот четверг! Как всегда - это была крутая практика с вопросами, которые помогли её улучшить.
Не все смогли присутствовать онлайн или спланировать этот вечер, чтобы успеть на вебинар. А часовые пояса - отдельная тема для откладывания на потом.
Поэтому мы подготовили возможность посмотреть повтор в удобное время, чтобы вы не упустили важную тему по архитектуре систем для системных аналитиков:
Запись вебинара:
📌 Проектирование архитектуры: от монолита к микросервисам
🗓 Только 2, 3 и 4 марта
🔗 ПОЛУЧИТЬ ДОСТУП
Мы благодарим всех, кто смог подключиться онлайн в этот четверг! Как всегда - это была крутая практика с вопросами, которые помогли её улучшить.
Не все смогли присутствовать онлайн или спланировать этот вечер, чтобы успеть на вебинар. А часовые пояса - отдельная тема для откладывания на потом.
Поэтому мы подготовили возможность посмотреть повтор в удобное время, чтобы вы не упустили важную тему по архитектуре систем для системных аналитиков:
Запись вебинара:
📌 Проектирование архитектуры: от монолита к микросервисам
🗓 Только 2, 3 и 4 марта
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18❤10👏2🎉2
На практическом вебинаре на прошлой неделе я показывала вам схему архитектуры без применения нотаций моделирования. А стандарты по проектировани схем архитектуры полезно знать. Расскажу сегодня про один из них 😉
Нотация моделирования C4 - это подход к визуализации архитектуры программного обеспечения, созданный Саймоном Брауном. Появился он в результате чтения лекций по архитектуре на курсе 🙂
C4 состоит из четырех уровней представления:
1. Context: высокоуровневый взгляд на систему. Показывает приложения и пользователей, без технических деталей.
2. Container: углубляет представление системы, описывая основные части, или "контейнеры" (backend-приложение, веб-приложение, мобильного приложение, базы данных, файловая система), которые входят в состав системы. На этом уровне определены функции каждого контейнера, технологические решения по языкам программирования, протоколы взаимодействия.
3. Component: детализирует каждый контейнер, описывая его компоненты и их взаимодействие.
4. Code: наиболее детальный уровень, описывающий внутреннюю структуру каждого компонента. Часто используются UML-диаграммы для его описания. Не обязателен.
C4 помогает представить сложные системы простым и понятным образом, что делает его популярной нотацией моделирования архитектуры для аналитиков и архитекторов ПО.
Удобнее всего создавать С4 в draw.io. Но есть и альтернативные инструменты. Например - Miro!
🟢 Делюсь ссылкой на шаблон + пример C4 для Miro 🟢
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🔥11👍3👏2
Можно всё и ещё больше ❤️🌹❤️🔥
Сегодня девушки могут достигнуть высот в карьере и бизнесе, доказывая, что нет ничего невозможного. Много девушек-коллег в IT очень преданно, ответственно и с любовью относятся к своей работе. И нереально много работают. Зато благодаря своим усилиям и стараниям всегда добиваются результатов. И могут всё сами))
В этот весенний день я хочу напомнить себе и девушкам, что несмотря на всю нашу силу, следует помнить о легкости и о той уникальной энергии, которую мы можем принести в этот мир.
Пусть этот весенний день принесет радость! Пусть мужчины впечатляют и продолжают проявлять себя как джентльмены рядом.с вами, что особенно заметно в IT-сфере 💪
В мире технологий всегда есть место красоте, легкости и доброте!
С весной и прекрасным праздником! ❤️🌸
Сегодня девушки могут достигнуть высот в карьере и бизнесе, доказывая, что нет ничего невозможного. Много девушек-коллег в IT очень преданно, ответственно и с любовью относятся к своей работе. И нереально много работают. Зато благодаря своим усилиям и стараниям всегда добиваются результатов. И могут всё сами))
В этот весенний день я хочу напомнить себе и девушкам, что несмотря на всю нашу силу, следует помнить о легкости и о той уникальной энергии, которую мы можем принести в этот мир.
Пусть этот весенний день принесет радость! Пусть мужчины впечатляют и продолжают проявлять себя как джентльмены рядом.с вами, что особенно заметно в IT-сфере 💪
В мире технологий всегда есть место красоте, легкости и доброте!
С весной и прекрасным праздником! ❤️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23❤18🎉11👍2
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
💫 ПРОБЛЕМЫ В РАБОТЕ С ЗАДАЧАМИ НА ИНТЕГРАЦИИ 💫
В новом эпизоде подкаста мы погрузимся в проблемы разработки требований на интеграции систем, с которыми могут встретиться системные аналитики, а также обсудим варианты их решения.
Этот эпизод представляет ценную информацию для начинающих и опытных системных аналитиков, стремящихся разобраться в работе с интеграционными задачами и обеспечить стабильное взаимодействие систем.
1:18 - Что такое интеграции?
4:25 - Роль системного аналитика в процессе работы с задачами на интеграции.
11:41 - Как изменилась работа с задачами на интеграции за последние годы?
16:49 - Написал требования в соответствии с API-документацией внешней системы, а потом оказалось, что работает не так.
19:40 - Интеграция работала в продакшн и всё было хорошо, а потом всё внезапно сломалось.
22:57 - Что делать если предстоит интегрироваться с системой у которой еще нет API, а сроки горят?
26:18 - Разработчик системы, с которой предстоит интегрироваться, не предоставляет API и доступы, а задачу нужно реализовать, потому что сроки (P.S. Влиять через заказчика на внешнюю команду при возможности).
28:07 - Что, если вы тот самый разработчик, у которого просят API, но вам пока не до этого?
29:21 - Платные подписки и использование внешних систем. Примеры: DaData.ru, сервисы SMS-рассылок с поштучной оплатой со счета заказчика и другие.
31:58 - Разные структуры данных в разных системах: как собрать всё в нашей системе воедино? Про агрегаторы.
36:07 - Высокие нагрузки и длительное ожидание ответов. Асинхронные запросы и вебхуки.
39:37 - Не работал с видом API, по которому предстоит интеграция (REST API, GraphQL, gRPC, SOAP API и WebSocket - основные, посмотрите на них).
42:02 - Заключение и рекомендации
Эпизод доступен в:
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Apple Podcast
⏯ Castbox
⏯ Spotify
⏯ Amazon Music
Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!
В новом эпизоде подкаста мы погрузимся в проблемы разработки требований на интеграции систем, с которыми могут встретиться системные аналитики, а также обсудим варианты их решения.
Этот эпизод представляет ценную информацию для начинающих и опытных системных аналитиков, стремящихся разобраться в работе с интеграционными задачами и обеспечить стабильное взаимодействие систем.
1:18 - Что такое интеграции?
4:25 - Роль системного аналитика в процессе работы с задачами на интеграции.
11:41 - Как изменилась работа с задачами на интеграции за последние годы?
16:49 - Написал требования в соответствии с API-документацией внешней системы, а потом оказалось, что работает не так.
19:40 - Интеграция работала в продакшн и всё было хорошо, а потом всё внезапно сломалось.
22:57 - Что делать если предстоит интегрироваться с системой у которой еще нет API, а сроки горят?
26:18 - Разработчик системы, с которой предстоит интегрироваться, не предоставляет API и доступы, а задачу нужно реализовать, потому что сроки (P.S. Влиять через заказчика на внешнюю команду при возможности).
28:07 - Что, если вы тот самый разработчик, у которого просят API, но вам пока не до этого?
29:21 - Платные подписки и использование внешних систем. Примеры: DaData.ru, сервисы SMS-рассылок с поштучной оплатой со счета заказчика и другие.
31:58 - Разные структуры данных в разных системах: как собрать всё в нашей системе воедино? Про агрегаторы.
36:07 - Высокие нагрузки и длительное ожидание ответов. Асинхронные запросы и вебхуки.
39:37 - Не работал с видом API, по которому предстоит интеграция (REST API, GraphQL, gRPC, SOAP API и WebSocket - основные, посмотрите на них).
42:02 - Заключение и рекомендации
Эпизод доступен в:
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Apple Podcast
⏯ Castbox
⏯ Spotify
⏯ Amazon Music
Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!
👍23❤6🔥1😍1
This media is not supported in your browser
VIEW IN TELEGRAM
Как правильно реализовать выгрузку файлов в облако: практическое руководство в этом видео 🧐
Февральско-мартовские выходные подходят к концу, и мы снова возвращаемся в бодрый рабочий темп после мини-отпуска!
С понедельника перейдём к разбору нового проекта в GetAnalyst, а пока отдыхаем и в фоне слушаем новый выпуск подкаста🎙
Крутого воскресенья! Проведите его с удовольствием! 💛
Февральско-мартовские выходные подходят к концу, и мы снова возвращаемся в бодрый рабочий темп после мини-отпуска!
С понедельника перейдём к разбору нового проекта в GetAnalyst, а пока отдыхаем и в фоне слушаем новый выпуск подкаста
Крутого воскресенья! Проведите его с удовольствием! 💛
Please open Telegram to view this post
VIEW IN TELEGRAM
😁25❤9👍1
Привет! Возвращаюсь к вам с новыми проектами на интеграции! 😌
Я не повторяю проекты, чтобы пополнять базу знаний GetAnalyst и рассматривать разные практические задачи, подходить к темам с разных сторон.
В этот раз выбор нового проекта дался мне не просто. Хотелось показать:
1. Любой API с авторизацией, с которым можно сделать интеграцию, чтобы рассказать о том, как писать требования и в чём могут быть сложности.
2. Нестандартный API, чтобы все в канале узнали для себя что-то новое.
3. Постановку задачи на интеграцию на все 100%: фронтенд, бэкенд, БД, маппинги и остальное.
И, казалось бы, это типовые задачи любого проекта с интеграциями, даже нестандартные API уже встречаются чаще, чем раньше. Бери и показывай 🙂 Но не всё так просто для публичных разборов.
Я хожу к вендорам (разработчикам внешних систем, с которыми интегрироваться) и запрашиваю у них доступы к тестовым площадкам. В открытую разбираю их API и документацию. Это возможно не с любой системой - увы. Не у всех открытая документация и доступы.
А ещё и запас известных API кончается 😀 Я уже много показала в рамках обучающих программ, открытых вебинаров и здесь в канале. И хочу новое каждый раз.
Путём исследований, напряжений памяти и фантазии нашла 3 проекта, которые можем сделать, с новыми API! Ура! 🎉
📌 Начнём с нестандартного API - интеграция через GraphQL.
Делаем мини-проект “Чеклист путешественника” или “Travel Points” - полный разбор с нуля: с постановкой задач на UI, БД, маппинги и интеграционные REST API бэкенда.
Начнём проект сегодня! ❤️
Я не повторяю проекты, чтобы пополнять базу знаний GetAnalyst и рассматривать разные практические задачи, подходить к темам с разных сторон.
В этот раз выбор нового проекта дался мне не просто. Хотелось показать:
1. Любой API с авторизацией, с которым можно сделать интеграцию, чтобы рассказать о том, как писать требования и в чём могут быть сложности.
2. Нестандартный API, чтобы все в канале узнали для себя что-то новое.
3. Постановку задачи на интеграцию на все 100%: фронтенд, бэкенд, БД, маппинги и остальное.
И, казалось бы, это типовые задачи любого проекта с интеграциями, даже нестандартные API уже встречаются чаще, чем раньше. Бери и показывай 🙂 Но не всё так просто для публичных разборов.
Я хожу к вендорам (разработчикам внешних систем, с которыми интегрироваться) и запрашиваю у них доступы к тестовым площадкам. В открытую разбираю их API и документацию. Это возможно не с любой системой - увы. Не у всех открытая документация и доступы.
А ещё и запас известных API кончается 😀 Я уже много показала в рамках обучающих программ, открытых вебинаров и здесь в канале. И хочу новое каждый раз.
Путём исследований, напряжений памяти и фантазии нашла 3 проекта, которые можем сделать, с новыми API! Ура! 🎉
📌 Начнём с нестандартного API - интеграция через GraphQL.
Делаем мини-проект “Чеклист путешественника” или “Travel Points” - полный разбор с нуля: с постановкой задач на UI, БД, маппинги и интеграционные REST API бэкенда.
Начнём проект сегодня! ❤️
❤47👍19🔥15❤🔥8