Какие планы на задачи на этой неделе?
Anonymous Poll
43%
«Давайте уже после майски»🦥
57%
«Успеть до майских - любой ценой» 🔥
👍2🔥1😁1
🚀 Масштабирование: как справиться с ростом нагрузки?
Интро: Собрался с силами и буду постить понемного о ходе обучения в Яндекс.Практикум, кратко буду рассказывать про темы и ощущения.
Представьте стартап «УОМ» — онлайн-магазин, который начинал с тысяч товаров и сотен заказов в день. Но в Чёрную пятницу, сайт начал тормозить, а клиенты — жаловаться на ошибки.
Проблемы «УОМ»:
🔹 Сервер — один, мощный, но ненадёжный.
🔹 База данных — не справляется с нагрузкой.
🔹 Приложение — падает под нагрузкой, перезапуск занимает время.
🔹 Сайт — работает, но не отказоустойчив, а загрузка контента в других регионах медленная.
Что делать? Масштабировать!
🔹 Два основных подхода:
Вертикальное масштабирование — добавление ресурсов (CPU, RAM, HDD) к одному серверу.
➖ Ограничено физически, дорого.
➖ Не решает проблему отказоустойчивости.
Горизонтальное масштабирование — добавление новых серверов и распределение нагрузки.
➖ Сложнее в настройке, но даёт гибкость и отказоустойчивость.
Облачное масштабирование — гибридный вариант, использует ресурсы облаков (AWS, GCP и др.).
🔥 Методы горизонтального масштабирования
➖Репликация — копирование данных на несколько серверов (например, для ускорения доступа в разных регионах).
➖Шардирование — разбиение данных на части (по регионам, типам данных).
➖Кеширование — хранение часто запрашиваемых данных в памяти (например, топ-10 товаров).
➖Автоматическое масштабирование — динамическое добавление серверов под нагрузку.
📊 Профили нагрузки
➖Статический (нагрузка предсказуема, например, ночью мало пользователей).
➖Динамический (резкие скачки, как в Чёрную пятницу).
🔜 В следующих постах: Подробнее обсудим масштабирование и составные его части.
💬 А вы сталкивались с проблемами масштабирования? Делитесь в комментариях!
#БазыДанных #Масштабирование #DevOps #Backend #ЯндексПрактикумАрхитектура
Интро: Собрался с силами и буду постить понемного о ходе обучения в Яндекс.Практикум, кратко буду рассказывать про темы и ощущения.
Представьте стартап «УОМ» — онлайн-магазин, который начинал с тысяч товаров и сотен заказов в день. Но в Чёрную пятницу, сайт начал тормозить, а клиенты — жаловаться на ошибки.
Проблемы «УОМ»:
🔹 Сервер — один, мощный, но ненадёжный.
🔹 База данных — не справляется с нагрузкой.
🔹 Приложение — падает под нагрузкой, перезапуск занимает время.
🔹 Сайт — работает, но не отказоустойчив, а загрузка контента в других регионах медленная.
Что делать? Масштабировать!
🔹 Два основных подхода:
Вертикальное масштабирование — добавление ресурсов (CPU, RAM, HDD) к одному серверу.
➖ Ограничено физически, дорого.
➖ Не решает проблему отказоустойчивости.
Горизонтальное масштабирование — добавление новых серверов и распределение нагрузки.
➖ Сложнее в настройке, но даёт гибкость и отказоустойчивость.
Облачное масштабирование — гибридный вариант, использует ресурсы облаков (AWS, GCP и др.).
🔥 Методы горизонтального масштабирования
➖Репликация — копирование данных на несколько серверов (например, для ускорения доступа в разных регионах).
➖Шардирование — разбиение данных на части (по регионам, типам данных).
➖Кеширование — хранение часто запрашиваемых данных в памяти (например, топ-10 товаров).
➖Автоматическое масштабирование — динамическое добавление серверов под нагрузку.
📊 Профили нагрузки
➖Статический (нагрузка предсказуема, например, ночью мало пользователей).
➖Динамический (резкие скачки, как в Чёрную пятницу).
🔜 В следующих постах: Подробнее обсудим масштабирование и составные его части.
💬 А вы сталкивались с проблемами масштабирования? Делитесь в комментариях!
#БазыДанных #Масштабирование #DevOps #Backend #ЯндексПрактикумАрхитектура
👍8🔥4👏2👌1
Forwarded from TechMeetup | System analysis
TechMeetup #9 🤔 System analysis | МТС Финтех
Весна в разгаре, а это значит, что пора собираться на новый TechMeetup #9! В этот раз говорим о системной аналитике, разбираем кейсы, делимся опытом и ищем вдохновение.
👥 Главный вопрос: кто будет выступать?
Если у вас есть:
🎙 Интересный кейс из практики,
📷 Разбор сложного проект или неочевидного решения,
🗣 Мысли о трендах и инструментах в аналитике —
мы ждём ваш доклад!
Неважно, есть у вас готовый материал или только идея — заполните форму заявки, мы обязательно обработаем ваш отклик.
💡 Даже если у есть только идея, но вам кажется, что она может быть интересной, или вы просто чувствуете вдохновение — не стесняйтесь писать. Мы поможем превратить задумку в полноценный доклад и поддержим на всех этапах, начиная с идеи и до выступления.
По всем вопросам - пишите @ficusmom | @SayPoj
Детали:
🗓 Когда: 22 мая 2025;
📌 Где: Москва (офлайн) + онлайн;
Следите за анонсами, чтобы не пропустить регистрацию. А пока — предлагайте темы и становитесь частью коммьюнити!
TechMeetup | CFP: Подать доклад | Общалка и вопросы | Записи
Весна в разгаре, а это значит, что пора собираться на новый TechMeetup #9! В этот раз говорим о системной аналитике, разбираем кейсы, делимся опытом и ищем вдохновение.
Если у вас есть:
мы ждём ваш доклад!
Неважно, есть у вас готовый материал или только идея — заполните форму заявки, мы обязательно обработаем ваш отклик.
По всем вопросам - пишите @ficusmom | @SayPoj
Детали:
Следите за анонсами, чтобы не пропустить регистрацию. А пока — предлагайте темы и становитесь частью коммьюнити!
TechMeetup | CFP: Подать доклад | Общалка и вопросы | Записи
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2👌2
Как я учусь в Яндексе.Практикум на архитектора (и почему это кайфово)
Практика — вот что действительно цепляет! Наконец-то разбираюсь с темами, которые вечно откладывал, потому что задания заставляют не просто читать, а сразу делать.
Ловлю себя на мысли, что теперь любое задание встречаю фразой: «Ты ж архитектор!» 😎
Например:
▫️ Нужно спроектировать микрофронтенды? Открыл draw.io, нарисовал схему, расписал логику.
▫️ Собрать приложение на React из нескольких сервисов? «Ты ж архитектор» — микрофронты, интеграция, немного кода, готово. Не зря я начинал карьеру фронтендом и писал под ie6 (олды испытали боль)
▫️ Разобраться с базами и масштабируемостью? «Ты ж архитектор» — поднял в Docker Redis, MongoDB, настроил шардирование, репликацию…
Что в этом крутого?
Знания не висят в воздухе — сразу превращаются в реальные решения. И да, это безумно мотивирует!
А ещу я вспомнил почему терминал в IDE это удобно и быстро)
Кстати, а у вас есть такие «мантры», которые помогают браться за сложные задачи?
Практика — вот что действительно цепляет! Наконец-то разбираюсь с темами, которые вечно откладывал, потому что задания заставляют не просто читать, а сразу делать.
Ловлю себя на мысли, что теперь любое задание встречаю фразой: «Ты ж архитектор!» 😎
Например:
▫️ Нужно спроектировать микрофронтенды? Открыл draw.io, нарисовал схему, расписал логику.
▫️ Собрать приложение на React из нескольких сервисов? «Ты ж архитектор» — микрофронты, интеграция, немного кода, готово. Не зря я начинал карьеру фронтендом и писал под ie6 (олды испытали боль)
▫️ Разобраться с базами и масштабируемостью? «Ты ж архитектор» — поднял в Docker Redis, MongoDB, настроил шардирование, репликацию…
Что в этом крутого?
Знания не висят в воздухе — сразу превращаются в реальные решения. И да, это безумно мотивирует!
А ещу я вспомнил почему терминал в IDE это удобно и быстро)
Кстати, а у вас есть такие «мантры», которые помогают браться за сложные задачи?
👍9🔥4😁2
Burmistrov - It и около
Потребности и возможности В коммуникации есть две роли: источник потребностей и источник возможностей. Источник потребностей формирует территорию проблем, а источник возможностей освещает пространство решений. Связь с хроническими людьми-потребностями держится…
Помните пост про возможности? Вот встретил ещё визуализацию
— Не «Информация исчезнет через 5 дней», а «Информация будет доступна ещё 5 дней».
— Не «Договор расторгнут», а «Нужен новый договор».
— Не «Заплатите, иначе услуга будет приостановлена», а «Чтобы продолжать пользоваться, заплатите до 7 марта».
— Не «Услуга доступна не чаще 2 раз в год», а «Можно пользоваться 2 раза в год».
— Не «Информация исчезнет через 5 дней», а «Информация будет доступна ещё 5 дней».
— Не «Договор расторгнут», а «Нужен новый договор».
— Не «Заплатите, иначе услуга будет приостановлена», а «Чтобы продолжать пользоваться, заплатите до 7 марта».
— Не «Услуга доступна не чаще 2 раз в год», а «Можно пользоваться 2 раза в год».
👍7🔥7👌4
Планы на май
Внезапно все вышло из под контроля и май получается насыщенным
🗓15 мая - Москве. Секретное мероприятие с холиванрными аналитическими посиделками, следите за анонсами (@holivarno)
🗓17 мая - Минск. Т1 хот-код: ИТ Барбекю. Доклад уже приняли (https://t1-hot-cod.by/)
🗓22 мая - Москва. TechMeetup #9 System analysis. Буду в программном комитете и помогать с организацией. Приходите обязательно. (@tech_meetup)
🗓23-24 мая - Санкт-Петербург. Analyst Days 2025, мне еще не написали, что доклад принят, но в сетке он появился. (https://analystdays.ru/)
Если думаете, куда в этом году ещё пойти, вот я список мероприятий публиковал: https://bv-dev.ru/it-конференции-2025/
А вообще приходите везде, встретимся, пообщаемся, будет интересно!
Внезапно все вышло из под контроля и май получается насыщенным
🗓15 мая - Москве. Секретное мероприятие с холиванрными аналитическими посиделками, следите за анонсами (@holivarno)
🗓17 мая - Минск. Т1 хот-код: ИТ Барбекю. Доклад уже приняли (https://t1-hot-cod.by/)
🗓22 мая - Москва. TechMeetup #9 System analysis. Буду в программном комитете и помогать с организацией. Приходите обязательно. (@tech_meetup)
🗓23-24 мая - Санкт-Петербург. Analyst Days 2025, мне еще не написали, что доклад принят, но в сетке он появился. (https://analystdays.ru/)
Если думаете, куда в этом году ещё пойти, вот я список мероприятий публиковал: https://bv-dev.ru/it-конференции-2025/
А вообще приходите везде, встретимся, пообщаемся, будет интересно!
🔥7👍5🥰3
Что, кроме денежной компенсации, заставит вас это сделать?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Аркадий Морейнис про лайки:
1. Если вы пишете для удовольствия — считайте лайки. Если занимаетесь контент-маркетингом — плюньте на них.
2. Задача любого кусочка контента в контент-маркетинге — продвинуть читателя (зрителя) по воронке продаж хотя бы на один шажочек ближе к покупке. Поэтому самое важное в каждом посте (клипе, картинке) — это явный или неявный призыв к совершению этого маленького шажка.
3. Дело не в том, сколько людей лайкнуло, а сколько людей шагнуло. Я даже часто наблюдал обратную зависимость: чем больше людей лайкает — тем меньше из них действует. Например, у нас в посте есть целевая ссылка и призыв к действию. Если читатель сразу ушел по ней и там завис — зачем ему специально возвращаться и лайкать? А вот те, кто на призыв не поддался и по ссылке не ушел — дочитают до конца, поставят лайк и продолжат заниматься своими делами.
4. Чьи-то книги высоко оценивают профессиональные критики. А чьи-то — хорошо продаются. Если мы не знаем, что должен сделать человек, прочитавший наш пост или посмотревший ролик — мы хотим, чтобы он поставил лайк. Если знаем — замеряем конверсию в действие.
5. В общем, правильные метрики контент-маркетинга всегда должны лежать за пределами контента. Если мы зациклились на оценке контента — значит, мы перестали заниматься маркетингом.
#интересно
1. Если вы пишете для удовольствия — считайте лайки. Если занимаетесь контент-маркетингом — плюньте на них.
2. Задача любого кусочка контента в контент-маркетинге — продвинуть читателя (зрителя) по воронке продаж хотя бы на один шажочек ближе к покупке. Поэтому самое важное в каждом посте (клипе, картинке) — это явный или неявный призыв к совершению этого маленького шажка.
3. Дело не в том, сколько людей лайкнуло, а сколько людей шагнуло. Я даже часто наблюдал обратную зависимость: чем больше людей лайкает — тем меньше из них действует. Например, у нас в посте есть целевая ссылка и призыв к действию. Если читатель сразу ушел по ней и там завис — зачем ему специально возвращаться и лайкать? А вот те, кто на призыв не поддался и по ссылке не ушел — дочитают до конца, поставят лайк и продолжат заниматься своими делами.
4. Чьи-то книги высоко оценивают профессиональные критики. А чьи-то — хорошо продаются. Если мы не знаем, что должен сделать человек, прочитавший наш пост или посмотревший ролик — мы хотим, чтобы он поставил лайк. Если знаем — замеряем конверсию в действие.
5. В общем, правильные метрики контент-маркетинга всегда должны лежать за пределами контента. Если мы зациклились на оценке контента — значит, мы перестали заниматься маркетингом.
#интересно
👍5👏3🔥2
Обнаружен очень крутой сервис https://deepwiki.com/ закидываете туда свою ссылку на гит-репозиторий и получаете подробную документацию с описанием и схемами, пример: https://deepwiki.com/CrazyElephantX/Module-Federation-practice/1-overview
Посмотрел большие мощные сервисы, выглядит очень круто, закидывал кучу репозиториев смотрел, интересно.
Но сломать у меня тоже получилось) Есть у меня репозиторий на языке 1с)) https://github.com/CrazyElephantX/YR_accounting_pc сервис не справился.
Сисемные аналитики в стартапы больше не нужны)
Говнокодим и если получили финансирование, делаем ИИ документацию, а дальше уже подключаем архитекторов, аналитиков🗣
Посмотрел большие мощные сервисы, выглядит очень круто, закидывал кучу репозиториев смотрел, интересно.
Но сломать у меня тоже получилось) Есть у меня репозиторий на языке 1с)) https://github.com/CrazyElephantX/YR_accounting_pc сервис не справился.
Сисемные аналитики в стартапы больше не нужны)
Говнокодим и если получили финансирование, делаем ИИ документацию, а дальше уже подключаем архитекторов, аналитиков
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2😁1😱1💩1
Job Story, User Story, Use Case — что это и как они связаны?
Давай разберемся на примерах из финтеха, без заумных терминов.
1. Job Story — «Зачем мне это вообще?»
Это про потребности пользователя. Помогает понять, какие проблемы люди хотят решить, а не делать просто «фичу».
🔹 Пример:
👉 Зачем: Чтобы не делать продукт, который никому не нужен.
2. User Story — «Что я хочу сделать?»
Здесь уже идет про конкретную задачу пользователя в системе. Пишется так: «Как <роль>, я хочу <действие>, чтобы <выгода>».
🔹 Пример:
👉 Зачем: Чтобы разработка была сфокусирована на полезных фичах, а не на «кнопках ради кнопок».
3. Use Case — «Как это будет работать?»
Это пошаговый сценарий, как пользователь взаимодействует с системой.
🔹 Пример:
👉 Зачем: Чтобы все (разработчики, тестировщики, аналитики) понимали, как всё должно работать.
Как это связано?
〰️ Job Story → Какая большая проблема у пользователя?
〰️ User Story → Какую задачу он решает в системе?
〰️ Use Case → Как именно система ему помогает?
💡 Итог:
Сначала смотрим на потребность (Job Story), потом формулируем задачу (User Story), и в конце прописываем сценарий (Use Case). Так делаем полезные, а не абстрактные решения.
📌 А как вы обычно описываете требования? Есть свои лайфхаки?
Давай разберемся на примерах из финтеха, без заумных терминов.
1. Job Story — «Зачем мне это вообще?»
Это про потребности пользователя. Помогает понять, какие проблемы люди хотят решить, а не делать просто «фичу».
🔹 Пример:
«Когда у меня заканчиваются деньги до зарплаты, я хочу взять небольшой заём без процентов, чтобы не залезать в долги».
👉 Зачем: Чтобы не делать продукт, который никому не нужен.
2. User Story — «Что я хочу сделать?»
Здесь уже идет про конкретную задачу пользователя в системе. Пишется так: «Как <роль>, я хочу <действие>, чтобы <выгода>».
🔹 Пример:
«Как клиент банка, хочу оформить кредитную карту с льготным периодом, чтобы оплачивать срочные покупки, даже если денег нет».
👉 Зачем: Чтобы разработка была сфокусирована на полезных фичах, а не на «кнопках ради кнопок».
3. Use Case — «Как это будет работать?»
Это пошаговый сценарий, как пользователь взаимодействует с системой.
🔹 Пример:
1. Оформление кредитной карты:
2. Клиент заполняет заявку в приложении.
3. Банк проверяет клиента и одобряет лимит.
4. Система генерирует виртуальную карту и прикрепляет в приложение.
5. Физическая карта доставляется курьером.
👉 Зачем: Чтобы все (разработчики, тестировщики, аналитики) понимали, как всё должно работать.
Как это связано?
💡 Итог:
Сначала смотрим на потребность (Job Story), потом формулируем задачу (User Story), и в конце прописываем сценарий (Use Case). Так делаем полезные, а не абстрактные решения.
📌 А как вы обычно описываете требования? Есть свои лайфхаки?
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5🔥3👏1
В мае(получается сегодня) вступает в силу закон, регулирующий вопросы утечки персональных данных
За незаконные использование, передачу, сбор и хранение персональных данных граждан вводится уголовная ответственность до 10 лет лишения свободы
Для юридических лиц размер штрафов может достигать 15 млн рублей при утечке специальных категорий сведений, а в случае с биометрическими данными — от 15 до 20 млн рублей
В случае повторного нарушения штрафы могут вырасти до 3% объема выручки.
Что это значит? Надо срочно обновить в голове знания что такое ПД, посмотреть как вы у себя их храните, как вы получаете разрешение на хранения и вообще весь процесс работы с ПД освежить и возможно модифицировать.
Я понимаю, что у вас данные точно не утекут, но посмотреть стоит и возможно что-то модифицировать
За незаконные использование, передачу, сбор и хранение персональных данных граждан вводится уголовная ответственность до 10 лет лишения свободы
Для юридических лиц размер штрафов может достигать 15 млн рублей при утечке специальных категорий сведений, а в случае с биометрическими данными — от 15 до 20 млн рублей
В случае повторного нарушения штрафы могут вырасти до 3% объема выручки.
Что это значит? Надо срочно обновить в голове знания что такое ПД, посмотреть как вы у себя их храните, как вы получаете разрешение на хранения и вообще весь процесс работы с ПД освежить и возможно модифицировать.
Я понимаю, что у вас данные точно не утекут, но посмотреть стоит и возможно что-то модифицировать
👍3😁3👏2🔥1
Obsidian stats 2025-05-02
На текущий момент моя личная база знаний выглядит так:
- 854 заметки (+35)
- 117 вложений (+18)
- 971 файл (+53)
- 1609 ссылки (+106)
- 99779 слов (+20190)
- 193.33 МБ (+31.83)
- 684 Тэгов (+16)
- 1.884 Качество базы знаний (+0,049)
#Obsidian #БазаЗнаний
На текущий момент моя личная база знаний выглядит так:
- 854 заметки (+35)
- 117 вложений (+18)
- 971 файл (+53)
- 1609 ссылки (+106)
- 99779 слов (+20190)
- 193.33 МБ (+31.83)
- 684 Тэгов (+16)
- 1.884 Качество базы знаний (+0,049)
#Obsidian #БазаЗнаний
🔥5❤🔥3👍3
Как же прикольно яндекс wiki реализовали plant uml, даже в visual studio не так удобно и круто работает. Вы только посомтрите! Диаграмма не моя взял на real-world-plantuml иногда смотрю там, кто как делает кейсы, вдохновляюсь и критикую))
👍5❤🔥2🔥2
📢 Stateful vs Stateless: как хранить состояние приложения?
Сегодня продолжаю обучение в Яндекс.Практикум разбирался в подходах к хранению состояний приложений. Тема далась легко, почти все и так знал с практикой возникли сложности, уже хочу новый комп, желательно 64 гига оперативки и м4 процессор. Держите краткий дайджест:
🔹 Stateful – приложение помнит прошлые взаимодействия (например, сессии пользователей).
→ Минусы: сложнее масштабировать (нужны распределённые БД, кеши, микросервисы).
🔹 Stateless – каждый запрос независим (как в REST).
→ Плюсы: легко масштабировать горизонтально — просто добавляем серверы и балансировщик нагрузки!
⚖️ Балансировщики нагрузки – ключевой инструмент для Stateless:
• Распределяют запросы между серверами.
• Работают через API Gateway или Service Discovery (Развернул локально в докере APISIX c Consul).
💡 Вывод: Stateless – гибче для масштабирования, но Stateful нужен там, где важна история (например, корзина в интернет-магазине).
#ЯндексПрактикумАрхитектура
Сегодня продолжаю обучение в Яндекс.Практикум разбирался в подходах к хранению состояний приложений. Тема далась легко, почти все и так знал с практикой возникли сложности, уже хочу новый комп, желательно 64 гига оперативки и м4 процессор. Держите краткий дайджест:
🔹 Stateful – приложение помнит прошлые взаимодействия (например, сессии пользователей).
→ Минусы: сложнее масштабировать (нужны распределённые БД, кеши, микросервисы).
🔹 Stateless – каждый запрос независим (как в REST).
→ Плюсы: легко масштабировать горизонтально — просто добавляем серверы и балансировщик нагрузки!
⚖️ Балансировщики нагрузки – ключевой инструмент для Stateless:
• Распределяют запросы между серверами.
• Работают через API Gateway или Service Discovery (Развернул локально в докере APISIX c Consul).
💡 Вывод: Stateless – гибче для масштабирования, но Stateful нужен там, где важна история (например, корзина в интернет-магазине).
#ЯндексПрактикумАрхитектура
🔥5👍3👏3
Forwarded from Холиварные аналитические посиделки
Ты разработчик, аналитик или архитектор? Готов сразиться за ограниченные ресурсы и доказать, что именно твоя команда способна выжать максимум из минимума?
15 мая мы в Москве запускаем тестовый "Ресурсный баттл" - оффлайн-игру, где тебя ждет настоящая борьба умов, стратегий и нервов!
В этот день вы попробуете свои силы в формате MVP-проекта: быстро, дерзко, по-настоящему! Только 30 мест!
- Реальные задачи и ограниченные ресурсы
- Нестандартные решения и командная работа
- Адреналин, азарт и ценные инсайты
Готов испытать себя
Заполняй заявку и готовься к битве - выживут только сильнейшие!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2👏2
IaaS, PaaS и SaaS: почему системному аналитику важно разбираться в облачных сервисах?
Облачные технологии давно перестали быть просто модным трендом — сегодня это основа IT-инфраструктуры большинства компаний. Системному аналитику важно понимать различия между IaaS, PaaS и SaaS, чтобы правильно выбирать решения для бизнеса, проектировать архитектуру и общаться с разработчиками.
Давайте разберёмся, что это за модели и зачем они вам.
1️⃣ IaaS (Infrastructure as a Service) — инфраструктура как сервис
Примеры: AWS EC2, Microsoft Azure Virtual Machines, Google Compute Engine.
Что это?
IaaS предоставляет виртуальные серверы, хранилища, сети и другие базовые ресурсы. Компания арендует инфраструктуру вместо того, чтобы покупать физические серверы.
Почему это важно для аналитика?
Нужно понимать, как масштабируются системы.
Приходится выбирать между облачным и локальным решением.
Важно уметь оценивать стоимость владения (TCO).
2️⃣ PaaS (Platform as a Service) — платформа как сервис
Примеры: Heroku, Google App Engine, Microsoft Azure App Service.
Что это?
PaaS — это готовая среда для разработки и развертывания приложений. Вам не нужно настраивать серверы, только писать код и деплоить.
Почему это важно для аналитика?
Ускоряет разработку (меньше времени на инфраструктуру).
Позволяет фокусироваться на бизнес-логике.
Нужно уметь выбирать подходящую платформу под задачи проекта.
3️⃣ SaaS (Software as a Service) — программное обеспечение как сервис
Примеры: Google Workspace, Slack, Salesforce, Notion.
Что это?
Готовые облачные приложения, которые работают через браузер. Никаких установок, обновлений и серверов — только подписка.
Почему это важно для аналитика?
Многие бизнес-процессы уже автоматизированы SaaS-решениями.
Нужно интегрировать их в существующие системы.
Важно оценивать безопасность и compliance (GDPR, HIPAA и др.).
➡️Вывод: зачем системному аналитику это знать?
〰️ Эффективное проектирование архитектуры. Вы сможете предложить оптимальное решение: развернуть своё приложение на PaaS или использовать готовый SaaS.
〰️ Снижение затрат. Понимание облачных моделей помогает выбирать экономичные варианты.
〰️ Коммуникация с командой. Вы будете говорить с разработчиками и DevOps на одном языке.
〰️ Автоматизация процессов. Знание SaaS-решений позволяет быстрее внедрять инструменты для бизнеса.
Облака — это не будущее, а настоящее. Чем лучше вы разбираетесь в IaaS, PaaS и SaaS, тем ценнее становитесь как специалист.
#СистемныйАнализ #Облака #IaaS #PaaS #SaaS #IT
Облачные технологии давно перестали быть просто модным трендом — сегодня это основа IT-инфраструктуры большинства компаний. Системному аналитику важно понимать различия между IaaS, PaaS и SaaS, чтобы правильно выбирать решения для бизнеса, проектировать архитектуру и общаться с разработчиками.
Давайте разберёмся, что это за модели и зачем они вам.
Примеры: AWS EC2, Microsoft Azure Virtual Machines, Google Compute Engine.
Что это?
IaaS предоставляет виртуальные серверы, хранилища, сети и другие базовые ресурсы. Компания арендует инфраструктуру вместо того, чтобы покупать физические серверы.
Почему это важно для аналитика?
Нужно понимать, как масштабируются системы.
Приходится выбирать между облачным и локальным решением.
Важно уметь оценивать стоимость владения (TCO).
Примеры: Heroku, Google App Engine, Microsoft Azure App Service.
Что это?
PaaS — это готовая среда для разработки и развертывания приложений. Вам не нужно настраивать серверы, только писать код и деплоить.
Почему это важно для аналитика?
Ускоряет разработку (меньше времени на инфраструктуру).
Позволяет фокусироваться на бизнес-логике.
Нужно уметь выбирать подходящую платформу под задачи проекта.
Примеры: Google Workspace, Slack, Salesforce, Notion.
Что это?
Готовые облачные приложения, которые работают через браузер. Никаких установок, обновлений и серверов — только подписка.
Почему это важно для аналитика?
Многие бизнес-процессы уже автоматизированы SaaS-решениями.
Нужно интегрировать их в существующие системы.
Важно оценивать безопасность и compliance (GDPR, HIPAA и др.).
➡️Вывод: зачем системному аналитику это знать?
Облака — это не будущее, а настоящее. Чем лучше вы разбираетесь в IaaS, PaaS и SaaS, тем ценнее становитесь как специалист.
#СистемныйАнализ #Облака #IaaS #PaaS #SaaS #IT
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥4👌2
Forwarded from TechMeetup
TechMeetup #9 🤔 Analysis x МТС Финтех⚡ Регистрация открыта!
Пришло время закрепить своё место! 🎟
Мы уже сформировали программу из крутых докладов, регистрация открыта, ждем только тебя!
Почему стоит прийти?
🔹 Разбор реальных кейсов от практикующих аналитиков
🔹 Нетворкинг с единомышленниками
🔹 Онлайн-участие — если не в Москве
🔹 Ответы на вопросы, которые не всегда гуглятся
🗓 Когда: 22 мая, с 18:30 до 22:00 (онлайн и офлайн).
📍 Где: Москва, м. Технопарк, выходы 1, 2 или 3. Здание с вывеской МТС Банк, Медиарум.
🔗 Регистрация и подробнее о программе и всех деталях — на странице мероприятия.
Успейте записаться — количество офлайн-мест ограничено!
TechMeetup | CFP: Подать доклад | Analysis | Общалка и вопросы | Записи
Пришло время закрепить своё место! 🎟
Мы уже сформировали программу из крутых докладов, регистрация открыта, ждем только тебя!
Почему стоит прийти?
🔹 Разбор реальных кейсов от практикующих аналитиков
🔹 Нетворкинг с единомышленниками
🔹 Онлайн-участие — если не в Москве
🔹 Ответы на вопросы, которые не всегда гуглятся
Успейте записаться — количество офлайн-мест ограничено!
TechMeetup | CFP: Подать доклад | Analysis | Общалка и вопросы | Записи
Please open Telegram to view this post
VIEW IN TELEGRAM